Ayesha Askham

Yes, that's all well and good but Saii specifically asked folks on Main Server NOT to update until the DJ boards broke. Now broken DJ boards don't fit my definition of "not much" and it was scant comfort that Oz made great efforts to work out just what WAS happening on Magnum (though we are all grateful that the effort WAS made).

Now this is getting silly. OK Whirly, I forgot about the memory-use advantages of the 64 bit. I ought to have remembered that we made use of it on FS for quite a while and I did indeed see out of memory crashes on 32 bit viewers. Phil, I am puzzled. 512MB is 0.5GB surely. That is a heck of a big drop in a rather small ocean.

I think were are missing the point here. The 64 bit viewer IS going to be useful for those users whose OS operate on a 64 bit bus, but only marginally. The issue of extended VRAM is another matter entirely. Most modern GPUs have over 1GB of VRAM. Many have over 2GB. It is THAT which will make the huge difference to most. Extending the VRAM addressed by the viewer vastly improves the viewer's ability to process and render complex scenes quickly. That much I know from personal experience using both 32 and 64 bit versions of Firestorm and a test build of the LL 64 bit (which did have up to 2048MB texture memory option, Whirly) against the standard default viewer. So let's be clear: a 64bit LL viewer with only 512B addressable VRAM will not give any noticeable improvement, but one that can use more VRAM most assuredly will.

OK I got the wrong message and shouted before I heard the truth. Simply I found it inconceivable that the Alex-Ivy test viewer should have the extended VRAM and an issued version should not. I attributed unreasonable idiocy to LL for no good reason.. My bad, as they say. I hope the 64 bit LL viewer will be released soon. It is sorely needed.

Seriously? LL have issued the 64 bit viewer with a 512MB texture memory limit?? After all the testing we did??? That beggars belief!

Shawn I have two questions: 1) Which viewer are you using? 2) Which type of graphics card? If the answer to 2) is NVidia, which driver version are you on. If 384.76 please roll back the driver and try again to log in.

Ah well, thankYou Caleb and the release notes are up...great. IDID wonder, earlier today!

OK my error I didn't scroll down the new GSP to find the announcement. I clearly have not got used to this yet. Still, the release notes aren't updated so I have no idea exactly WHAT was rolled yet!

Thing is, Whirly I obviously went to bed prior to the posting of the roll announcement and failed to scroll down far enough to see it today, my error, I suppose. And yet....with nothing in this forum and no release notes, this is, I repeat SNAFU.

No Victorian they ARE doing restarts, it seems they just didn't bother to tell anyone...even their own Server Notes agent. *SNAFU*

I am a tad perplexed about today's un announced rolling restart to the Main Server. We at Woods of Heaven are now on 17.05.22.326523, yet the release notes in Help >About xxx show LAST week's server version with no mention of today's software. What is going on and why is there this confusion SNAFU yet again?

Just to close out this issue of cache sharing, Marine Kelley has reacted quickly and has issued an updated RLV which no longer shares its default cache with the Linden SLV. It DOES require that anyone who has previously been using the default viewer to change the cache location from preferences PRIOR to the first login with the new viewer, but once that is done all will be well.

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.

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.

@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?

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

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.

@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.

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.

@Whirly Thanks for demystifying the situation, Whirly.

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?

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!

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?

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.

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?