Rolling Restart for Server 1.30

Actually you don't understand lag at all:
http://analutetia.com/blog/anatomy-of-lag/

Thank you, Thank you, Thank you.

There is another test procedure regarding teleports and scripted attachments. If anyone was actually testing to those procedures, none of the server versions in the past year would have passed QA. The more scripted attachments you wear, the less likely TP's succeed. No scripted attachments are around a 95% success rate. Lots of scripted attachments are under 40%.

This really needs to be fixed as it requires you to nearly strip naked to TP. Region crossings in the last 6 months have also gone from a minor bump to an uncontrolled walk sometimes 2 sims away before you snap back to the original border.

TP's are not the only low-performing part of SL.

I've seen sim lag (time dilation and FPS) get dramatically worse as well in this time frame. Client performance has ALSO dropped with 1.23 being the slowest performing viewer in recent history.

The fact that I have a maxed out texture cache, log out, and log in again only to have to wait to reload all the same textures that were already loaded from before speaks volumes about just how incredibly broken the caching system is. God knows how much the extra bandwidth is costing LL for sending the same textures to clients 1000 times over and over.

Group chat remains a lag infested crapshoot, where messages in larger groups have a less than 50% success rate. The lack of a reasonable chat interface with people outside SL is deplorable. XMPP is a rock solid protocol that should replace the core of chat, and would allow integration with most IM networks outside of SL (AIM, Yahoo, GTalk, ICQ, etc.)


LL seems to want to attract corporate America and higher ed "business" customers to SL, but seems to be clueless about the fact that business's do NOT HAVE high end gaming systems. LL's blatant disregard for performance on low end (graphics wise) systems is making it impossible to go after the very market they so desperately desire. This is bad for the rest of us too as it means even high-end systems don't perform well.

Someone needs to take a step back and look at the direction you are going, 'cause things are not getting better.

They are they are giving you a whole day... or kinda heh

Some of us used to test software for a living, so I concur with the comments above. Perhaps a change in words is in order:

* Change Log - A running list of what is different on the Beta (Aditi) grid than the current production release. This should be kept up to date to what is actually running there.

* Release Notes - The final change log when a beta version moved to the production grid.

If we have access to the change log, then we can test the changes in Beta before you go to release. The week between pilot roll and full rollout is a good thing, that lets a reasonable number of regions test the new version in the production environment, before committing to the full grid.

People that plan events would disagree that five minutes is enough of a warning =)



These two links were our effort to provide you with what we could in that regard:

http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Beta_Server/1.30
https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Beta_Server/1.30_Beta_Test

Are you looking for something more?

http://jira.secondlife.com/browse/VWR-6110 - will this be fixed. Andrew Linden was trying to get it into the release.

SVC-4632 is not being worked on. I don't believe we have a way to reproduce it yet. If anyone can reliably reproduce it, please describe how in a comment on the jira.

This fix has been delayed until 1.32 because we don't have the resources/time to QA it before we release 1.30.

Dante, since you are in the mood to discuss what is being worked on, how about:

http://jira.secondlife.com/browse/SVC-4196

Or its related issue:

http://jira.secondlife.com/browse/SVC-3895

These seem particularly nasty to me, but no Linden has ever commented on them that I am aware of.

There are at least two approaches to scheduling releases that we could use. One is feature-based ("our next release will have features X, Y, and Z", and the other is time-based ("every N weeks, we'll release what's been implemented/fixed and tested so far".

The problem with the first approach is that delays in feature Z mean that features X and Y, which could be ready to deploy, don't get out onto the grid in a timely fashion.

We are using the second approach. We tell all the developers when we'll be doing releases, and if they finish their code and it gets tested in time to make it into the next release, then it can go in. If not, then the code waits until the next release following the completion of that testing. This gets features like X and Y onto the grid at a somewhat regular interval without concern over the fact that feature Z might be one or two months behind. This does mean that the feature list for a release will be more variable than if we were taking the first approach and releasing specifically to get features X, Y, and Z onto the grid.

Whats 'nothing big is changing'... there is always something big changing, otherwise why spend the time effort, money to do it.. maybe just to p*** us off more?

I have to ask, without making this personal, but what are LL doing drafting someone in to do a job, that has no experience doing it? They sack the last person on the spot? They had no time to plan the move?

Server updates means one thing.. undetermined amount of time when we cannot go about our business... I don't mean the first update, but all the rollbacks and new updates that will follow.

I'll bet anyone a pint, we get ghost prims back this update... its on my calender, like the full moon cycles.

Funny how little some people know of what goes on in SL... we dont all spend our time playing in sandboxes.. some of us spend months planning many events of many types, that require coordination, collaboration and timing.... in the middle of it we get.. region will be restarting in 5 minutes.....

4196 is a known issue with the way a simulator rezzes objects. The more attachments or the larger the object being rezzed, the longer the pause will be. We allow a delay of up to 15 seconds. If someone is rezzing an object on land they own, the delay can be up to 30 seconds. This behavior is touched on here:

https://support.secondlife.com/ics/support/default.asp?deptID=4417

The dev that 3895 is assigned to is on vacation. I'll ask him for a status update when he returns.

Yeah, that's exactly what we do. You can follow the beta release notes to see what changes with each deploy to the beta grid, and when that's all finalized and we're about to deploy to the production grid, we make the non-beta release notes.

Let me get this right...

...a full simwide pause of everything (all scripts, all avi movement etc.) up to 30 seconds is acceptable or "expected behavior"?

Even if it wasn't an issue prior to 1.26?

Even if its something that gets worse with time/use similar to a memory leak?

OK, added the link to 1.30 beta release notes here:

https://wiki.secondlife.com/wiki/Category:Release_Notes_for_Beta_Versions
https://wiki.secondlife.com/wiki/Category:Release_Notes_for_Beta_Versions

That was the missing link, the notes were up, but not connected to anything else in the wiki, so we were having a hard time finding them.

Isn't it scary that with the grid seemingly pulling itself apart at the seams the last week or two, that the roll-out of 1.30, which according to the beta release notes has a surprisingly small number of fixes, has been delayed another week?

No offense, Cinca, but you weren't here to know what it was like when your statement would have been true. The grid is rock-solid compared to those days.

Besides, September 15 is when the new Adult Rating enforcement begins, so have to get that code up to snuff and ready to rock-and-roll on the servers.

Due to the delayed deployment, we'll have time to include the fix for http://jira.secondlife.com/browse/VWR-6110.

/me watches SVC-4616's continued lack of Linden Lovin'.

How about some Linden Lovin' for SVC-22 before the new script limits come in?

Oh, Argent. You know two-digit JIRAs aren't to be worked. They're museum pieces, part of the heritage to be left to new generations of newbies.

Oops, I got the pjiras mixed up. Sorry! We're including a fix for VWR-12525, not VWR-6110.

Yeah...how is SVC-4616 not, like, the top priority?