Sanctuary – blog post
Server Deployments
As always, please refer to the server deployment thread for the latest updates.
- There was no deployment / restart to the Main (SLS) channel on Tuesday, March 6th, leaving it on server maintenance package 18#18.02.12.512536.
- The main RC channel should be updated as follows on Wednesday, March 21st:
- The BlueSteel RC should receive a new server maintenance package. 18#18.03.17.513365 is said to comprise “internal fixes”.
- The LeTigre and Magnum regions should receive a new server maintenance package. 18#18.03.14.513292, comprising internal fixes, additional logging to help diagnose an issue with in-world HTTP servers returning HTTP 503 (BUG-214702); add two new capabilities: one to request IMs that were delivered to the requesting agent while the agent was off-line; one to request the most up to date list of abuse report categories.
New Capabilities
The new capabilities in 18#18.03.14.513292 for Magnum and LeTigre are the first part of a set of server an viewer updates.
- The new IM cap is to overcome of off-line IMs failing to be delivered when a user logs in. Currently, these are delivered via UDP, whether or not the viewer is ready to receive them. With the new capability (once grid-wide and implemented within the viewer), the viewer will request off-line IMs, which the server will package and deliver to the viewer via HTTP.
- The new abuse report cap will replace the need for the viewer to have AR categories hard-coded into it. Once fully deployed, and a viewer update released, it will mean the view will request the current list of AR categories from the server when starting up, making the management of the list easier, and hopefully reducing the number of ARs filed under outdated categories.
SL Viewer Updates
There have been no updates to the current selection of official viewer at the start of the week, leaving the pipelines as follows:
- Current Release version 5.1.2.512803, dated February 23rd, promoted March 1st – formerly the Nalewka Maintenance RC.
- Release channel cohorts
- Project viewers:
- Linux Spur viewer, version 5.0.9.329906, dated November 17th, 2017 and promoted to release status 29 November – offered pending a Linux version of the Alex Ivy viewer code.
- Obsolete platform viewer, version 3.7.28.300847, May 8th, 2015 – provided for users on Windows XP and OS X versions below 10.7.
Region Crossings
As noted over the last few weeks, user Joe Magarac (animats) has been digging into region crossings, particularly looking at the issue of avatars getting unseated from vehicles (See Firestorm JIRA FIRE-21915, this SL Forum thread, and this Google document, plus my last update here for more).
His latest approach involves adding a script to a vehicle effectively turns off physics and freezes the vehicle when received by a new region until it can confirm the associated avatar data has arrived (using llGetObjectDetails (avatar, [OBJECT_ROOT]) to check for the presence of avatars). On confirming the avatars are present, the script check the vehicle is allowed to resume.
“The typical freeze time is 40-120ms in addition to the regular region crossing delay, so you barely notice.” Joe told me in discussing the approach, which he has now made available to those wishing to test it using a simple motorbike build. “For double region crossings, the vehicle should slow down, although not by too much. I’ve also tried the same script in aircraft, and it seems to work.”
Joe continued, “Right now, I want to see if it ever fails. Issues are logged to an external server, so I can see what’s going on. I’d also love to get some of the SL motorcycle clubs involved in testing , so I’m giving out these test bikes. However, if anyone wants to test the script with their own vehicles, they can contact me for a copy, and I’ll be happy to work with them.”
Again, this workaround isn’t intended to solve all region crossing issues (e.g. it won’t stop “rubber banding” or address motion prediction – which the Lab sees as probably too aggressive), but it should help with full or partial avatar unsits; so those interested in given it a go are welcome to drop Joe a line.
Other Items
SL Messaging Layer
“I’m looking at the messaging layer; that seems to be the problem behind a lot of laggy things,” Simon Linden stated during the SUG meeting, revealing some of his recent work.
“There’s been a lot of learning. That code is complicated and there’s actually a lot of wisdom written into it, but I’ve found it doesn’t really do the best things when packet loss increases. The most basic thing I’ve found is that the estimated times based on pings used for time-outs can grow too fast: like on a 100ms connection, it can jump up to using 5-10 seconds. There’s a balancing act between resending data, and thinking it needs tons of time to get there.
“It really goes bad if a ping packet or the reply gets lost. SL just uses the same time-out for each retry – that’s another part that could be smarter.”
Defining this as an “interesting” part of the code, he’s reasonably certain it could be doing things better – and in doing so, could also help with region crossings and overall updates.
He also noted that also the SL bandwidth code is broken. This appears largely due to the volume of traffic going over the HTTP caps and via the CDN(s), which isn’t counted. “So I’m pretty sure we clog up a narrow pipeline more than we should,” he added.
Inara Pey: Living in a Modemworld 