Ayesha Askham

  • Content count

  • Joined

  • Last visited

Community Reputation

9 Neutral

About Ayesha Askham

  • Rank
    Too young to not misbehave, too old to care.
  1. Yes, you are quite correct, Whirly and what is more disturbing is that there appears to be widespread ignorance of this issue inworld from what I can gather. I am surprised and concerned that RLV should use the same Cache location as the SLV. That needs attention, in my view.
  2. Bigmoe you almost make my point for me. The maintenance had commenced several days before I posted (see for yourself). The completion post was several days after I'd tested the site and found it working properly. I am guessing that the completion notice had simply not been posted when the work was completed. ETA: The way the GSP is constructed now makes finding that particular piece impossible so let's just leave it. The work was done but as is so often the case the person responsible for posting the completion notice either didn't bother to do it or for some reason couldn't.
  3. @Whirly That is news to me, it certainly WASN'T shared before! I shall look at this and correct it promptly! And fixed. D'oh! It take it that RLV uses OpenJPG?
  4. Thankyou for those kind words. I wish that I could say that all is now well, but though better, there is definitely still an issue. I logged in and performed a series of teleports using first FS 64, then the current "default" viewer, and finally the current RLV (I have tested other viewers but none actually use the current render code so they are not relevant). I have still seen delayed texture delivery and also certain assets are slow to arrive, though none that are cached locally now, thank goodness. The report is @ https://jira.secondlife.com/browse/BUG-100683
  5. OK I am an idiot I had checked so many things to ensure that my system was not at the root of what I was seeing. But not everything. At some point in the recent past an update to my Windows Firewall (which I tied in with my Bullguard Security routine) had been updated and the "allowed programmes" set to default. I now suspect that it was THAT that was causing the issues I was seeing. I shall monitor the situation and if I am wrong I will be sending my logs to a JIRA for LL to peruse. But for the meantime I am sitting in the naughty corner and sorting my system out.
  6. @Whirly Will be doing just as soon as I fix a little issue with zipping up logs. The main problem is that some of the log files apparently don't have the specific info that Oz wants, but I think I know how to get it. I am astonished that no-one else has yet filed a JIRA submission on this.
  7. OK, I won't stand by and listen to all this without commenting. Firstly it is NOT necessary to run the default Linden-provided viewer for days to establish whether or not a particular issue is client or server based. Secondly, while Linden Lab may not be directly responsible for the experiences of users accessing SL via third-party viewers they ARE responsible for the system that feeds into those clients and a large proportion of the rendering code in MOST of them. US corporate responsibility has been cited many times over the last decade as a "get out" route for service providers; many US ISPs are still doing precisely that today. I identified this particular issue some days ago using several clients, all of which exhibited exactly the same symptoms. Having eliminated my router and ISP in general from the equation and also my computer, I was left in no doubt that data was not being supplied to the clients in a timely manner, though in ALL cases (bar the "official" client) increasing the fetch request rate produced a moderate improvement. It is simply that as a result of some throttling in the journey from the SL server to the client, data, be it textures, assets or several other classes of data, in not arriving at the clients in a timely manner. Maybe "simply" is a bad choice of words; issues in SL are rarely simple. Now whichever way you cut this, the responsibility for this poor performance is Linden Lab's, either directly or as a result of a failing at one of their network of collaborating operators. All that having been said I am not holding my breath for LL to provide a transparent solution. Despite what Oz said they already have more than enough information to be going on with, had they the motivation to address this issue.
  8. @Whirly Thanks for demystifying the situation, Whirly.
  9. Something is tickling my Spidey sense here. I see from the Status blog that there is no mention of Magnum regions being rolled AT ALL, despite what Mazidox posted above. Now that coupled to the unplanned re-rolling of LeTigre and Cake has me reaching for my protective Foil Hat. Is something going on that we wot not of?? I suppose it's too much to expect some explanation from The Lab?
  10. It's more than just "interesting". We see there has been a second tranche of Rolling Restarts to LeTigre regions today. Why? So far as I could tell the LeTigre region I visited last PDT afternoon after the first set of restarts seemed to be working OK - and was on the advertised server version - indeed better than usual, considering its heavy script-load. Now this and I ask again why? I just went to look and it now seems that LeTigre has been pushed to the server version slated for BlueSteel and Magnum regions yesterday. So I guess changing everything wasn't a good idea. Quel Surprise!
  11. OK I'm being stupid (not for the first time) but something is being moved to http from UDP in the near future (I am vague on the actual timing). If it is not inventory is it perhaps asset rendering or something? I recall being told by someone at The Lab or one of the FS devs that it was something that required both server-side and client-side changes and that the client-side changes would be "pretty major", with a timescale running from Spring to Summer this year. Is this something of which you know O Whirly One?
  12. Yes, this is now a new issue within SL. I did wonder if it was my router or my ISP until it began to be clear that many folk from several geographic regions were seeing the same issue. Bearing in mind LL's averred intent to move inventory fetching to http, this gives me cause for concern since inventory loss is already a problem for a fair number of folk. The CDN has worked fairly well overall, but poor texture delivery has been a frequent issue since it was set up, so one has to wonder if LL's collaborators are "up to stuff". I hope that this simply is a side-effect of the server-changes needed to implement http inventory.
  13. So For four days now we are to believe that Linden Lab technicians are struggling to make the My.Secondlife.com work properly? Or have the Status Blog folk simply forgotten to update the post? For me My.Secondlife.com and profiles seem to be working well so what is the issue?
  14. It is good to see Monty in this thread, it gives us reason to think that SOME at Battery Street (or wherever LL is now) are paying attention. As both Prok and Chic have correctly noticed, the backups that we users can make are utterly useless if the asset vanishes from the SL asset-server. It is the ASSET SERVER cluster that needs LLs attention because it is there and only there that the assets which vanish from our inventories (which are merely pointers) actually exist. Once they go all copies and pointers vanish too. I have pointers in my inventory that point to vanished items, most likely in the creator's inventory. If I pass such an item, despite transfer permissions, to my Alt, the item vanishes, because as far as the asset server is concerned it no longer exists. Backup can only have an utility if it occurs at the Asset-server level, where it has some existence. Dear God, have you noticed how old people tend to repeat things...now where did I put my glasses......
  15. OK guys, play nicely please. I for one do not wish to return to the flaming and bad blood spilt in these Fora in past times. @Prok: Caleb's posts are vital in my view to allow us to post sensibly here if things inworld do NOT go as the techs at LL expect (this happens rarely but sufficiently often to warrant this thread). Your annoyance ably elucidated in another topic in this thread should not result in ill-advised and bad-tempered posts in this one. From my conversations inworld and out, I suspect that these asset-server losses are a function of the hardware not necessarily the software so while they MAY be BUGS, they may be unavoidable. That does NOT mean that they cannot be made less permanent and damaging. @ Phil: Prok's posts are not all about one individual. Prok represents a large number of users that have suffered losses and it is well past time that something was done to ameliorate this situation.