Endless – blog post
Server Deployments
Please refer to the server deployment thread for the latest news.
- There was no deployment to the SLS (Main) channel on Tuesday, February 26th, leaving it on server maintenance package 19#19.01.25.523656. As regions on the channel were restarted in week #8, there was no restart this week.
- The planned deployment was cancelled due to a list minute issue being found, and also led to the planned RC deployment(s) being postponed.
- No deployments are planned for Wednesday, February 27th, 2019, leaving the RCs on the following simulator versions:
- BlueSteel and LeTigre: server maintenance package 19#19.02.16.524516 EEP).
- Magnum: server maintenance package 19#19.02.16.524515, comprising further internal fixes.
- Simon indicated at the SUG meeting that regions on the RC channels might be restarted, although this is unclear, as the channels have not hit the 14-day restart barrier.
SL Viewer
There have been two recent RC viewer updates:
- On Tuesday, February 26th, the BugSplat RC viewer updated to version 6.1.0.524670.
- On Friday, February 22nd, the Estate Access Management (EAM) RC viewer updated to version 6.1.0.524240.
The rest of the viewer pipeline remains as follows:
- Current Release version 6.0.1.522263, dated December 5th, promoted December 13th. Formerly the Spotykach Maintenance RC viewer – No Change.
- Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
- BugSplat RC viewer, version 6.1.0.524348, February 13th. This viewer is functionally identical to the current release viewer, but uses BugSplat for crash reporting, rather than the Lab’s own Breakpad based crash reporting tools.
- Love Me Render RC viewer, version 6.0.2.523177, January 16th.
- Project viewers:
- Linux Spur viewer, version 5.0.9.329906, dated November 17th, 2017 and promoted to release status 29th 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.
Inventory UDP Messaging Deprecation
The planned deployment to Magnum (cancelled for this week) should include the updated simulator code that removes all asset fetching UDP messaging from the simulator code. Once deployed, this will mean anyone using really old viewers that do not have HTTP asset fetching on regions running on the Magnum RC channel will no longer be able to obtain responses to asset requests – and this will increase as the code is deployed to the remaining channels.
It’s not clear yet if the two “legacy” viewers currently offered by the Lab (the Linux Spur viewer and Obsolete Platform viewer) will remain available after the update has been fully deployed, as both will be unable to fetch assets. Those wishing to test older versions of viewers against the updated simulator code can do so on Mesh Sandbox 3 on Aditi.
The Question of Script Load
The core of the SUG meeting revolved around the question of scripts and simulator loads. The discussion started with a request to make scripts run % data accessible to SLS, so scripters might coder periodic, intensive scripts hold off loops of execution if they can see a region is busy.
This spun out to a discussion of making information on scripts (as seen at the region level via Top Scripts) available at parcel level. However, a concern here is the risk of unnecessary drama: if X on parcel Y can see top scripts across the region, and sees A’s scripts on another parcel gobbling script time, it could lead to an assumption (right or wrong) it is the scripts that are responsible for all issues X is experiencing, resulting in potential local drama.
Another idea put forward is to make script use tied to parcel size (as is the case with land capacity / impact) in an effort to make script usage fairer within a region (see BUG-225391). While potentially good in theory, such a “fair use” approach has some potential issues:
- Script usage isn’t balanced by parcel within a region. It is possible to have multiple parcels using little or no script time, and one using more than its “fair share”. Currently, this means things can balance out within a region, but with a capped script use, the “high use” parcel could be penalised when there is no need. As Oz Linden noted, “We could do that, but suppose we did. In many places people would see a big script performance drop even though the region had lots of idle time.”
- Scripts are the only thing that can impact local performance: Physics Time, for example, can be over-used and impact performance, leaving very little script time per frame.
- There is a difference between in-world scripts and attached scripts, so there is a question of how would the latter be accounted for? Making them part of the parcel allowance isn’t necessarily fair, as the parcel owner has no direct control over others without something of a draconian approach (depending on parcel size) – upping the potential for drama / upset.
Simon Linden also pointed out that there is pretty significant overhead moving between the scripts versus running actual bytecode (that is figuring out what to run against actually running it), so monitoring everything could add more of an overhead than actually letting scripts run – although there have been discussions on how to improve this. But, he also cautioned that adding further checks would have to be a “real clear win”.
There are some reports that the percentage scripts run seems to be falling across Mainland, without a noticeable increase in script count, which if true, would indicate something is going wrong. But as pointed out at the meeting, without data, it is hard to tell what is going on. Is a slow-down a case of having too much useful stuff going on for the available resources, or is it a case of someone going compute-bound in their script, lagging a region.
This is likely to be a discussion that will continue.
Inara Pey: Living in a Modemworld 