Tuesday saw the roll out of the HTTP Package Monty Linden has been working on. This ran on all three RC channels last week. The package has to do with changing the connection protocols used between your viewer and the Second Life™ servers.
A few people are reporting an increase in PING time. I haven’t seen it yet.
Some are complaining about region crossings. Simon Linden discussed crossings with us in the meeting.
Simon Linden: I know Monty and others have done lots of load testing [for HTTP] and tried to measure that [texture and mesh download times]. I’m not closely involved with the [HTTP] project but I hope it hasn’t gotten worse.
That code [HTTP] is all over the grid now, so I’m sure we’ll hear it if there are new problems. I know we’ve been hearing about slow crossings especially with vehicles a bit more lately.
Kitto Flora: My conclusion – it’s not the version of sim code. It depends on how much network traffic you have. It’s directly related to your Net traffic rate when you cross. If its 500k – fail maybe 20% of time. If its 50k, it rarely fails.
So it appears to me that the critical ‘crossing into new sim’ packet(s) are failing – being lost – if the traffic rate is high. It smells of ‘no-reliable’ packet [UDP] being lost.
Simon Linden: Yeah, I’d believe that. The exchange between a viewer, the old region and the new region is pretty complicated. It doesn’t like losing packets or data. I wouldn’t be surprised if there’s a mix [of reliable HTTP and no reliable UDP]. [However,] there are a bunch of different places it can fail.
In response to whether avatar crossing speed makes a difference, Simon: Your speed in-world shouldn’t have any effect on actually making it or not, but faster crossings will show the errors in predicting where objects will be more. Such as the rubber band effect when crossing … your viewer sees you going a certain speed, and keeps moving you that way, while you hit the crossing, get some lag as the data is transferred to the new region, and you’re stuck into the world, then sling-shot back to the new position. That looks worse when you go fast.
Having lots of scripts and mesh makes it worse because there is more data to pass between the two regions.
Qie Niangao asked: Is there also an extra delay when crossing into an idle region? Like it takes a while to wake up? Or is that just coincidence / my superstition? (I don’t really know that the region is idle before I get there, and then it’s not… kinda like the refrigerator light.)
Simon Linden: Qie – you actually shouldn’t ever be able to do that. It won’t be idling if you can see into it.
Kitto Flora: When flying I do see regions that appear to be idling – or unresponsive to new child Avs . As I approach they are ‘invisible’ and you usually bounce of the border. After some seconds they appear, then you can cross.
Simon Linden: The non-visible neighbor regions have typically been a different problem. Also, remember idle regions are not dead, they [are] just are running at a slower frame rate, just like loaded down regions do.
Blue Steel and Le Tigre were to get a new package this week. Simon tells us that may not happen. There are some ‘scheduling’ problems and the package may not make it. We won’t know for certain until Wednesday.
Magnum channel is going to get the Animation Overrider update and more bug fixes. This version should have the poseball fix. If things go as Simon expects, this package will roll to all RC channels.
The problem of regions not being visible before crossing into them is still with us.
There is a sandbox just for weapons testing. The problem is it currently has scripts turned off. Presumably that is because of griefing.
There are always griefing fixes being added. Presumably this will get fixed.
There has been a problem where objects between 255 and 256m could not be returned. Simon says that fix is in the Magnum rollout. (BUG-313 and BUG-2021) Seems there are problems with objects on and just over the border, 0 to -4 and 256 to 260. Hopefully this fix resolves that.
If you are finding objects around the region boundary that cannot be returned and/or are not auto-returning, file a JIRA. The Lindens think this is fixed. So, without prompting, they are on to something else.
You can visit the sandbox Plum to see the problem with auto-return failing. Hopefully tomorrows rollout will fix the problem. Once the region restarts auto-return should start working. If you are there late in the day and nothing has changed, it is JIRA time.