SL project updates week 44/1: Server, CDN update

The Pines at Jacob's Pond, Jacob; Inara Pey, October 2014, on FlickrThe Pines at Jacob’s Pond, Jacob (Flickr) – blog post

Server Deployments Week 44

As always, please refer to the server deployment thread for the latest information and updates.

Main (SLS) Channel

On Tuesday, October 28th, CDN support was deployed across the Main channel, meaning that the entire grid now utilises the Highwinds CDN for texture and mesh fetching.

As the 130 regions deployed to the Snack channel were all originally from the Main channel, they have been / will be reabsorbed into that channel, and Snack will once again be dissolved.

Release Candidate Channels

On Wednesday, October 29th, all three RC channels should receive the same server maintenance project. which includes some minor improvements.

SL Viewer

There are currently two RC viewers possibly vying for promotion to the de facto release viewer. These are the HTTP Pipelining RC (version and the Benchmark viewer (version, which should put an end to the use of a manually maintained list of GPUs in order to initially set the graphics defaults in the viewer.

Both of these were updated on Friday, October 24th, which has delayed any promotion to the de facto release viewer while the Lab gathers performance statistics on both of them. commenting on the status of both during the Simulator User Group meeting on Tuesday, October 27th, Oz Linden indicated that all things being equal, the HTTP Pipelining viewer should be promoted in the next 24-48 hours. He also indicated that there may be a further round of updates to come to Benchmark viewer in the offing as the Lab continued to tweak it.

CDN: Next Steps

In the vast majority of cases, the CDN is working as expected for users. There is a very small minority who, possibly because of their geographical closeness to the Lab’s servers or possibly due to issues between their ISP and the Highwinds services, are experiencing slightly worse ping times to their nearest CDN nodes when compared with pinging the Lab’s servers directly.

Even with the deployment to the Main channel, the Lab is continuing to monitor reports from CDN closely. However, as previously mentioned in my CDN coverage, it is likely the scope of CDN usage will be expanding in the future to handle other asset data – sounds, animations etc.

Also, and as noted in my week 43 TPV Developer meeting report, an offshoot of the CDN work is that there is a belief within the Lab that viewer caching may not be working as well as it might be. Internal discussions have held on possibly validating whether or not this is the case, and it is likely some work will be carried out in this area – and may well involve TPVs.

However, where both the viewer cache and extending the use of the CDN to cover other asset data are concerned, there are no time frames currently in mind. At the moment, the focus is very much on get the new tool chain and build process for the viewer finalised and into production, and in dealing with bugs and issues. As such, it might be a while before specific work on the viewer cache and / or work on extending the use of the CDN gets underway.

On a wider front, as well as monitoring the direct effectiveness of the CDN service, the Lab will be “spending quite a bit of time and effort assessing just what the effect of this change has been on operations from a number of perspectives”, to quote Oz.

Other Items

LI Issues?

There are reports circulating of unexpected changes to Land Impact (LI) values. While the Lab hasn’t altered land accounting, there have apparently been incidents of LI suddenly increasing in builds which have gone unchanged; one instance quoted during the Simulator User Group meeting referenced a door which apparently increased from 0.5 LI to 3 LI.

There have been instances in the past of the viewer incorrectly reporting the LI for an item when it is pulled from inventory. Corrections can generally be made either by relogging or by returning the item to inventory and rezzing it again. Altering the physics shape of linksets (from prim to convex and back again) can sometimes lead to problems, particularly if a prim in the linkset is contains torturing (such as a hollow or advance cut / twisting) or a script. However, this issue appears to be new, and a cause is proving hard to identify.

As always, if you have encountered the problem, and it is both persistent and reproducible, please raise a bug report.

Graphics Profiles in the Viewer

A suggestion was put forward during the Simulator User Group meeting for the Lab to allow the saving of graphics profiles. This would mean, for example that you could have a graphics profile where various options – the quality slider, shadows, occlusion, draw distance, etc., could be pushed towards their upper limits; and another where the setting are more conservative and less taxing on your GPU / system.

Then, where you are in a region (your own, or somewhere you know), where you know you can use the higher settings, you can quickly enable that profile, but when you move on to a region where (say) there are a lot of avatars and a lot going on, you can select the more conservative profile and thus reduce the potential performance issue on your system without actually having to go through and manually adjust all your settings.

Responding to the idea, Oz suggested the idea might be best suited to being a code contribution – and there was some potential interest in taking the idea on. However, this does not guarantee the idea will be carried forward – but it will be interesting to see if the idea does move forward at all in the coming months.

4 thoughts on “SL project updates week 44/1: Server, CDN update

  1. The graphic profiles thing sounds very interesting, though considering that most, if not all of the possible graphics settings are essentially a part of what is stored in settings.xml, I think it would be trivial to make it so this feature just lets the user load different settings.xml files on the fly, therefore allowing the user to change just about anything… not just what’s in the Preferences > Graphics tab, but other things as well, including obscure Debug Settings. Currently this is somewhat possible using different .xml files loaded through duplicated shortcuts, but this of course requires to relog, so it’s kinda clunky (of course, if this profiles thing is implemented, the user should be made aware that some particular settings still would require relogging to take effect).


    1. Yep, the grahpics work was not seen as too intensive by those discussing it.

      That there are many settings (not just graphics-related) that could be stored / changed on the fly also came up, but then there’s the risk of scope creep, trying to address too much, etc. Focusing on the core graphics settings that can make a difference when moving between regions with different traffic loads, etc., gives a reasonable target to aim for. There was also a feeling in the discussion that this could be achieved sans a relog.

      At the moment, there’s no commitment to carrying the idea forward from anyone, although interest was expressed; hence my sketching just the outline of the idea. There may be more to report if the idea gets picked-up 🙂 .


Comments are closed.