#SL News 2 Week 37

Interest List

The interest list is all about how fast things rez and download due to the number of requests being made. A small number of requests complete quickly and the viewer can go about rendering the newly downloaded stuff.

Server-Scripting Meeting 9/2012

Figuring out what you are looking at so the viewer knows what to request from the server is a bit of a chore. Andrew Linden has been working on improving the interest list to improve performance.  This week (37) his code is moving into testing.

We should be seeing it on the ADITI grid. The changes are server side. No viewer changes are required, if I understand correctly. So, the effect will show up quickly not having to wait on viewer QA.

Andrew says there is an experimental change that could cause some viewers to use more memory. For now he has that disabled. Andrew says they will test that feature with a custom viewer and decide how much of an impact it has. Then they’ll see if they can better coordinate the viewer and server for better performance and less memory use. He did not get into the details… of those details…

However, if the changes reduce bandwidth use and improve cache use, they will probably build a project viewer and get changes to the third party developers. So, there are some weeks of work ahead before we see the full release of these changes.

Main Channel

Unless you are a new reader, you know the channels are groups of regions that update to the same version of server software. The main channel is what everyone thinks of as the Main Grid or the Second Life™ world.

This week saw the roll out of a new package to the main channel. This roll out contained the bandwidth fix people were wanting. Due to problems it took longer than was expected. Things happen. But, it finally made it.

Along with the bandwidth fix a large number of other fixes rolled out too. You can see the full list in either the release notes or the Deploys thread.

This week (37) the roll out to the main channel took longer than usual. The grid was described as fighting back during this update. Oskar and Coyot Linden could not find a reason for the problems. Then 85% of the way through the roll out Coyot’s (release engineer) laptop failed. Oskar explained the event as, “…bad sectors in the boot partition and mid meeting it just crapped all over itself. So that made the last part of the rollouts take longer because he had to switch machines. ”

Release Candidates Channels

The RC channels are three groups of regions in the main grid, AGNI. They make up about 20% of the grid and they are used to test new server software.

This week a much smaller package of fixes is being run. For some reason the same package is being run in all three RC channels. This is usually done when they have a package they want tested under the widest range of conditions. Or… other packages are not ready, which usually means they are stuck in QA on the preview grid. I’m not sure which it is the case this week.

Fewer sets of fixes in a package mean it is more likely to pass testing. Unless something goes sideways this weekend, this smaller package should roll to the main channel next week (38).

The planned package contains Bug Fixes:

SVC-8146 is the primary concern and I think the reason the package was kept small. The Lindens want to get that fix out on the grid.

There were problems so the RC roll did not happen until Thursday. That was due to Coyot’s computer dying and having to be replaced. It’s hard to find duel floppy drive systems these days…

There are some region crash problems they were tracking down Thursday and hoped to be able to decide Friday whether the current RC could roll out.

Coming Updates

Mæstro Linden gave us some information on coming updates currently in progress.

…one project we mentioned earlier is still in the works. The one with all the 3rd party library updates and new Havok update. That maintenance release has fixes for [viewer] large group member lists. My understanding is that the large group fixes also include some viewer changes.

There’s also a maintenance release which will probably be ready for RC next week. That maintenance release has localization updates for several server messages.

It turns out that the project with the Havok update (DRTSIM-172) will require the maintenance release (DRTSIM-173) to be everywhere first. I think that DRTSIM-172 is a few weeks away at least.

Mæstro mentioned that Kelly Linden has a handy new feature coming out that is in one of these releases… but, he then realized it has not officially been announced so he stopped talking and shot everyone that heard him say anything… So, something is coming and we don’t know what.

SIM State Save

When regions restart the state of the region prior to shutdown is saved into a backup. This includes all the prims and scripts in the region. If a script is counting from 1 to 1,000 and it is at 500 when the region starts shutting down, when the region comes back up the script should continue counting from 500.

There are rumors circulating that region states on shut down are not working as they should. The result is regions roll back to an earlier time when restarted.

Andrew thinks Simon and Kelly Linden are looking into that problem. If you are seeing it when your region restarts file a bug report and mention Simon and Kelly in the report.

Region state is saved every hour. So, theoretically a roll back should only be for a state saved at most an hour before the shut down.

One of the owners a large number of regions says they see one or two people complain each roll out. So, it would seem to be somewhat rare.

Mesh Road Bumps

Yeah… mesh roads still bump at the seams. Using a prim overlay on the seam does not help.

I saw this technical article mentioned by Indigo Mertel on Plurk. She is a good person to follow for interesting headlines and links. See Drongle McMahon’s: Single convex hull physics weights (long and technical) . I may try to write a simplified English translation some day.

Basically this means there currently is not an easy fix for bumpy mesh roads.

Summary

Lots of things are changing in Second Life. The viewer, servers, procedures, an alliance with Valve, the Deformer is basically complete, materials are coming… the next few months should be interesting.

3 thoughts on “#SL News 2 Week 37

  1. One of the owners a large number of regions says they see one or two people complain each roll out. So, it would seem to be somewhat rare.

    It could also be that people pay some attention — possibly because they’ve learned the hard way, as have I and some of my tenants — to heed LL’s warnings about not rezzing stuff during rolling restarts, at least not during the last hour or so before the normal restart time.

    Certainly the figures Lucia Nightfire has been posting at SVC-7959 suggest that significant server time loss during restarts is not that uncommon.

    • For those that run into it, I have no doubt it is a problem and annoying. It still seems rather rare. Even a 1,000 reports would only be 3% +/- of the regions. But, that may just be the appearance from reports filed.

      I’m curious how Lucia Nightfire is capturing the information. If there is a script that captures the info, we could get more region owners recording data. Then we would know the extent of the problem based on objective information.

      This is the type of problem that a closed JIRA makes hard to diagnose and especially hard for users to evaluate. For now the SLUniverse thread with big reports is the only recourse.

  2. I really don’t think it’s safe to infer much from how many reports are filed. Certainly when it’s happened to me, I’ve not bothered to ask for a roll-back. It’s annoying to lose half-an-hour’s work, certainly, but not worth asking LL to do a roll-back over. Similarly, I’ve always told tenants that I’m unwilling to ask for roll-backs, and that first they should approach the makers of any no copy items they’ve lost (and they’ve always had them replaced).

    I guess someone could ask Lucia how she gathers the data. One way to do it, I think, off the top of my head, would be to have a script advancing a counter once a second and sending the results to another sim or an external database. If things are working correctly, when the sim restarts, the counter should pick up where it left off. If it’s reverted to a lower number, you can calculate when that must have been saved. I think that would work, though I’m open to correction.

Leave a Reply to Nalates Urriah Cancel reply

Your email address will not be published. Required fields are marked *