SL projects update week 30 (2): Upcoming server & viewer releases, SSA, HTTP

Server Deployments Week 31 (Week Commencing Monday July 29th)

As always, please refer to the week’s forum deployment thread for news, updates and feedback.

Second Life Server (SLS Main) Channel

On Tuesday July 30th, the SLS Main channel should receive the server maintenance package previously deployed to BlueSteel in week 30. This project fixes some miscellaneous bugs, and also allows viewers to send requests for materials data more rapidly.

On Wednesday July 31st, the three main Release Candidate channels should be updated as follows:

  • BlueSteel should receive a new server maintenance project.  This project fixes some bugs related to LSL scripts in child prims of linksets, and also addresses some server crash modes
  • Magnum and LeTigre remain SSA enabled and both receive the updates deployed to the Main channel.

Server-side Appearance

As noted in the planned deployment summary above, it is currently not anticipated that SSA will be enabled on any additional channels in week 31.

Overall, the Lab think the initial phase of deployment is going well, and recognise the considerable contribution made by TPVs in enabling this to happen. A rough approximation from viewer statistics suggests that around three-quarters of users logging-in to SL are using viewers which are SSA-enabled, and that the overall figure may be higher.

A chart compiled by Kadah Koba showing the percentages of SSA-enabled and non-SSA viewer in use (excluding Firestorm 4.4.0)
A chart compiled by Kadah Coba showing the percentages of SSA-enabled and non-SSA viewer in use (excluding Firestorm 4.4.0)

Commenting on the state of play for the project during the TPV Developer meeting on Friday July 26th, Nyx Linden said:

The system is working pretty much as we expected … and even the scaling of how much load is being generated is pretty much right on par with what we’re expecting. But we want to make sure that a few other things are returning the right things and we’re getting the right statistics that we want before we roll it out to the [entire] grid. We’re trying to be extra-cautious.

Viewer-side Updates

In terms of viewer-side updates, the plan is to try to have one major post-SSA enabling release which should include the planned inventory updates noted in the first part of this report along with any additional viewer-side code tweaks to the viewer arising from SSA being enabled, and a final code clean-up to remove the “old” baking code.

However, this does depend on enabling SSA on the rest of the grid. If there is yet cause to delay this (due to an unexpected issue arising, for example), and the delay continues for a significant amount of time, then it is possible that there will be two viewer releases: one with the currently planned updates and one with the post-deployment code clean-up.

Either way, to assist TPVs prepare for the viewer-side update(s), Nyx plans to periodically push code from the Lab’s private repositories to their public repositories as and when code is in a suitable condition to be pushed.

Issues Update

SUN-98 (Bake fail resulting from partially broken alpha layer): this is thought to be the result of wearing a corrupted clothing layer, and if so is considered to be expected behaviour in order to avoid cases of “accidental nudity” (which might arise from wearing a corrupted clothing later, which the SSA system would ignore and just bake whatever was underneath it  – such as the avatar’s skin). However the matter is still being looked into in case the problem has another cause.

Nyx acknowledged that even if the problem is due to expected behaviour, it would be useful  “at some point in the future” to add some UI elements to actually show the user which clothing asset they’re wearing that is causing the problem. What form these UI elements / warning will take remains to be decided.

SUN-99 (Bakefail on SSA regions only. When entering into SSA region, skin and system clothes fail to bake): this issue only affects a very small number of users and appears to be related to them having multiple copies of the Current Outfit Folder (COF) in their inventories, probably as a result of having moved it  within their inventory (i.e. into another folder) at some point prior to the Lab introducing restrictions to prevent the COF being moved or deleted.

To prevent this happening in the future, the Lab is implementing further back-end restrictions and other improvements on the COF, and Nyx has e-mailed all TPVs with notes on how the COF should be implemented within the viewer in order to comply with these restrictions.

In the meantime it was mentioned at the Server Beta meeting on Thursday July 25th that LL’s support team can now assist users who find they are suffering from this particular issue.

Viewer Updates

Release Candidates

As noted in part one of this report, there are now three RC viewers in the viewer release channel (Beta Maintenance, Google Breakapad and Vivox). All three are performing well, although no decision has been made as to which will be going to release status first.

Beyond these, the Lab is looking at a number of further release candidate cohorts, including the Cocoa updates for the Mac version of the viewer, a series of open-source contributions to the viewer, and a further series of CHUI updates.

Commenting on the current situation with viewer updates at the TPV Developer meeting, Oz Linden said, ” It’s going to be some time before we get to the point where we’ve got the number of simultaneous things happening down to a reasonable number; lots of stuffing was sitting around waiting for the opportunity to get out, and it’s all coming at once now!”

People gather for the TPV Developer meeting, Friday July 26th
People gather for the TPV Developer meeting, Friday July 26th

Materials Processing Updates

Work is continuing on update to materials processing, although it is expected that it will be a while before any changes move from the project viewer to a release candidate cohort, as there are still a few bugs the Lab wants to fix.

Interest List Viewer

It is anticipated that a test / project viewer containing the interest list updates will be appearing in the Alternate Viewer wiki page “pretty soon” (together with links to the code on the Viewer Source Repositories page). In fact, Oz indicated he had included it in his notes for the TPV Developer meeting as it had been anticipated that the viewer would be available now.

Experience Tools

Work on the Experience Tools project is continuing with server-side updates for the last couple of weeks. These have stirred-up a lot of anticipation as to what the tools may in fact be, and when they might become visible in a viewer.Responding to the latter and the TPV Developer meeting on July 26th, Oz Linden said:

The project’s in the pipeline behind the visible ones, and I’m not in a position to predict when it will become visible. This is one of those things where we have to have lots of back-end infrastructure in place before there’s any point in putting the front end out where people can see it, because if we put the front end out before people can do anything with it, it’ll just seem to be broken.

So patience remains the order of the day.

HTTP 1.1

Monty Linden
Monty Linden

Monty Linden is continuing to work on the HTTP side of things, looking specifically at mesh uploads and downloads, with the of improving both by getting keepalives going with mesh and reducing the overall number of connections used during an upload / download.

“Most of that is looking good,” he informed the TPV Developer meeting on Friday July 26th. “Looks like I’ve been able to knock it down to about a quarter with the number of connections; the viewer’s currently using 32, but I’ve knocked it down to eight, which should leave a few routers in place that are currently falling over.”

The work requires two simulator releases as well as the viewer-side updates he’s producing, and these are currently stuck behind the work to enable SSA across the grid. This needs to be completed before Monty can get his first server-side update deployed. Currently, Monty hopes to get a project viewer out in August and possibly ahead of the server-side changes, although this may slip as he’s still dealing with some issues.

One this work has been done, the next project Monty has set for himself is to work on HTTP pipelining. There are no time scales for this as yet.

Group Ban List

Appearing at the Server Beta Meeting on Thursday July 25th, Baker Linden repeated his update on progress with group bans (see part 1 of this report), noting that he has been working on the XUI elements in the viewer and, “hooking them up and making it work properly”.

As a part of the work, Baker is looking to include the ability to add multiple names to the ban list in a similar way to extending multiple invites to join a group (using the people picker), so that known trouble-makers can be pre-emptively banned from a group, rather than only when they’ve actually joined the group (and started to cause problems through spamming, etc.).

Other Bits

Texture Rendering

There have been some reports of object textures failing to render properly (hair, wall textures, etc.), but remaining blurred when in view. This appears to be happening on non-SSB/A regions but is not necessarily related to SSB/A. If you are noting this issue occurring frequently and in specific regions, please file a bug report.

Inventory Fetch Failures

There are also reports of people suffering from inventory fetch failures with v3-based viewers. While the numbers are declining, if you do encounter the problem, please file a bug report with your viewer dev team (if possible) or LL (if using the official viewer). Monty Linden has been alerted to the problem and, providing information reaches him in a timely manner via the various support teams, he has offered to try an assist with investigations.

Related Links

7 thoughts on “SL projects update week 30 (2): Upcoming server & viewer releases, SSA, HTTP

    1. Instances of the issue seem to have significantly decreased, however, as a result of recent viewer updates.

      Like

  1. I have a friend who was using one of the new V3 code based viewers, and his inventory wouldn’t load, so in turn nothing else would either. All the old standby fixes didn’t work either to fix it. I have not had an issues that bad, and seen no others with it. He had to switch to another viewer without the modern code. I geuss a few people are experiencing reloading of materials repeatedly they blur in, and then stay for a second then do it again, and again. I am sure there still a many number of bugs that needs some ironing out.
    Typical of new code.

    Like

    1. The blurring / clearing / blurring of textures could be a case of “texture thrashing”. This is, I understand, particularly noticeable on systems where the virtual address space is filling up (on a 32-bit Windows system limited to 3 GB of RAM, for example) and / or the graphics VRAM (on older graphics cards which had less RAM than their more modern counterparts) is getting filled.

      When this happens (again, assuming I’m correctly understanding how it was explained to me), textures start to get “discarded” – that is, rendered at a lower resolution (where 0 discards is full resolution, 1 discard is 1/2 resolution, and so on) in an attempt to reduce the amount of memory / address space being used. When this happens, the viewer might display a small “number of textures discarded” message in the lower right of the screen).

      As more memory / address space is cleared, textures again start to render properly and memory / adress space fills up, and the cycle repeats with textures being rendered at lower resolutions once more, leading to a cycle of textures rendering, blurring, rendering, blurring.

      Ideally, the viewer should discard textures which are far away, making room for those closer (and more like to be in line-of-sight). However, it appears as if there may be a caching issue which results in the viewer bouncing between textures which are closer to the camera and those which are further away, particularly in cases where high draw distances are being used, with the result ot “close” textures get discarded. A final problem here is that when textures are discarded (e.g. have a value of 1 or more), they do not appear to be cached locally, and so must be retrieved from the server in order to render correctly, all of which puts a greater strain on both server and viewer.

      The interest list work has seen some work carried on on the viewer-side caching, but as noted in this update, the project viewer has yet to surface. Hopefully when it does, the caching improvements might help to lessen some of the impact of this issue for some people. Longer term, there have been hints from the Lab that further work on caching could be forthcoming in the future, and an unofficial suggestion has been put forward that caching is something TPVs and the Lab might be able to work on as a joint project at some point.

      Like

      1. Since caching is generally a solidly understood topic in Computer Science, I find it a little disturbing that we appear to have such a long-running problem. It could well be the Interest List system making odd choices of what is visible, rather than the actual caching.

        One possibility: would a shorter draw-distance minimum in the Lab viewer be helpful? I haven’t used it for a while, but that last time I did the minimum was 128 metres. Many TPVs go down to 32m. Downside is it can mess up 64m prims: it looks as though you need to have the centre of the prim inside your draw distance to be sure of rezzing it.

        Like

        1. It’s possible the two side are still out-of-sync as well, despite the initial viewer updates made during the interest list work, and this might be compounding matters given there has been a set of delays in getting the remaining viewer-side updates out in a project viewer. Minimum DD is an idea, but again, how many people on older hardware will simply push past it, giving their systems a hard time with potential texture thrashing?

          About the one positive we have here that given caching is a long-running problem (and one which is grossly misunderstood within the user base, to be fair – look at how many times people point to clearing cache as the panacea for all viewer-side – or percerived viewer-side – problems), is the people are starting to look at it more deeply, and there has been the informal suggestion made from the Lab’s side for the Lab and TPVs to work to further improve things.

          Like

Comments are closed.