Note: with the exception of the server deployment review, the majority of this update has been taken from the TPV Developer meeting held on Friday 21st August. A video of the meeting, recorded by panterapolnocy, is available at the end of this article
Server Deployments Week 34
As always, please refer to the week’s forum deployment thread for news, updates and feedback.
- On Tuesday August 20th the Main channel had Server-side Appearance (SSA) enabled, as per this blog post from the Lab.
- On Wednesday 21st August, the Magnum RC received a new maintenance package with “under the hood” changes which should be invisible to residents, while BlueSteel and LeTigre received an update to the package deployed to BlueSteel in week 33. This includes a fix for the “grey box” attachment issue which affected multiple avatars riding an object over BlueSteel region crossings. Additionally, these channels also saw SSA enabled, meaning the entire main grid is now running SSA.
SSA Update
For information on the Server-side Appearance deployment, please see my separate report.
SL Viewer Updates
A new release candidate debuted on August 20th with the name “CHUIStorm” (3.6.4.280048). This is a merging of the CHUI and Snowstorm RC viewers with the latest de facto release code base. The reason for merging the two RCs is because the Lab felt there were “too many RCs in flight”, making it difficult to determine which one should be promoted to the release viewer if several appeared ready simultaneously. In future, the Lab hopes to keep the total number of RCs in the channel to around two or three.
Interestingly, the Google Breakpad RC has vanished from the list of RC viewers in the Release channel.
The Materials project viewer was promoted to the Release channel on August 21st (RC 3.6.4.280083), leaving the current total number of RC viewers in the channel at three (CHUIStorm, Cocoa (Mac) and Materials).
Next in the Pipeline
While the order in which they appear or the overall time frame for their release is not clear, there are a number of project viewers which will be appearing in the near future. These include:
- A further Snowstorm project viewer (third-party developer contributions) – currently with LL’s QA team
- A new Interest List project viewer (which has had trouble passing QA – see below)
- A further SSA project viewer – for details see my SSA Update
- A Group Bans project viewer (see below)
- An HTTP project viewer (see the HTTP update below)
In addition, Oz Linden hinted that he may have a surprise announcement at the next TPV Developer meeting in two weeks. While he said absolutely nothing further on the subject, the resultant speculation was that he might have been referring to the arrival of an Experience Tools project viewer. Linden Lab accidentally exposed such a viewer a few weeks ago, but quickly moved it back to a private status, so there is an awareness that a viewer is in development. Whether the speculation is right or wrong will be revealed in the fullness of time!
Interest List Update
As noted above, the viewer-side updates to the Interest list project continue to evade a project viewer release, but are expected to appear “soon”. While the code does not contain any mandatory changes TPVs must adopt, there are obviously optimisations within the code which will be beneficial for TPVs to pick-up once the repository is public.
Group Ban List
Baker Linden continues to make good progress with the group ban list project. He is currently working on what he sees as the last major part of the initial work: getting the viewer connected to the server. After that, he reports he has “a lot of security checks, and some minor additions”. There’s still no date for a project viewer, but it would appear that it is not that far from reaching a status of “real soon now”.
HTTP Update
Monty Linden is continuing to work on his HTTP updates, although he has most recently been trying to get the ” bureaucratic details” sorted and getting a QA pass on both the server-side and the viewer side work. He’s also trying to get a DNS fix in as well, which he describes as the “great DNS look-up failures problem” which the Lab has had for a number of years. He thinks he has a fix for the issue, but he’s not 100% certain.
In terms of the HTTP work, Monty is trying to get a project viewer lined-up, and describes the major feature within it as being the reduction of the number of connections used by mesh so that it will be possible to start using keepalives with mesh as well.
As I’ve previously reported, Monty has already reduced the number of mesh connections from 32 to 8. Going forward, eight will be the new default (rather than 32), with the aim being to cap the total number of mesh connections used by the viewer, with adaptive throttling and two different re-try schemes. The hope is that this will further improve network utilisation by creating more effective viewer / server connections; it should also help less capable routers.
The Myth of MeshMaxConcurrentRequests
One of the myths which surround mesh in SL is that the higher the number of connections set via the MeshMaxConcurrentRequests debug setting, the better the result. This has led to people massively exceeding the current default of 32 with values in the 100s – 500 being very common.
However, as Monty and Oz Linden both pointed out at the TPV Developer meeting, setting a high number of concurrent mesh connections is generally counter-productive and a case where more is not generally better. It abuses the network, exceeding SL’s service capacity and risking possible congestive collapse.
In order to reduce these issues, Monty plans to clamp the number of connections the viewer will allow in his upcoming HTTP project viewer, and a request has been made for TPVs to do the same*. At the same time, the Lab will be “taking a hard look” at clamping the figure from the servers if possible; the desire being to “provide better capabilities in the viewer to do the right thing and better protection in the server against people who aren’t doing the right thing”.
For those using a high MeshMaxConcurrentRequest setting, Monty also had something of a warning:
Some of our throttle controls do have memory. And when a viewer abuses them, it’s not immediately forgiven. So, people who are doing things like 500 concurrent connections , that is actually being registered, and we are responding to it.
After giving his warning, Monty went on to say of the myth that high MeshMaxConcurrentRequest = “better”, “It is just utterly counter-productive, and is one of those things that should be forgotten as quickly as possible”. So if you have set the figure to well above the default of 32, it is probably in your best interests to reduce it once more.
Another, more direct reason for clamping the number of connections is in preparation for HTTP pipelining. The aim here is to eventually combine mesh and HTTP texture request paths into a single channel. This should allow the Lab to further improve connectivity between the viewer and their servers, resulting in a better service on both sides of the equation.
In discussing this, Monty indicated that the HTTP capabilities he is working on at the moment will use a new capability – Mesh2MaxCocurrentRequests – which will be clamped at 8. As there will be a period of transition across the grid as the new HTTP capabilities are being deployed, wherein both the current and new capabilities will co-exist, so the Lab will be looking to clamp the existing MeshMaxConcurrentRequests. Monty anticipates that when this happens, the setting will be clamped at “well under 100”.
Other Items
For the Future: Animation Override LSL Functions and the Viewer
During the TPV Developer meeting on Friday August 10th, (see my notes here) a series of questions were asked on whether Kelly Linden’s work on adding server-side LSL AO capabilities might at some point herald the arrival of a client-based AO capability within the LL viewer which could leverage them.
Having promised to take this back to the Lab after that meeting, Oz was able to provide a further update:
I checked-in with the relevant server devs and they said, “Yeah, in theory we could do that” … If there’s interest in making that happen, what I’ll want is for someone other than me to be prepared to do some of the work on the viewer side to figure out what the interfaces should look like and test them and so on.
He went on to say that the scope of the project can be “as large or as small” as might be required, and asked that if anyone in the TPV arena is interested in working on the project-to-be to let him know, and he’ll attempt to get the ball rolling on a formal footing. This immediately drew an offer from Kitty Barnett on the grounds that she originally raised the questions. Also, Kitty already has a solid track record of working with the Lab, having made several code contributions to the viewer, such as the spelling checker, and has more recently worked on materials processing.
Viewers and ALM
Since the release of materials processing, a question Oz Linden is frequently asked is whether he has stats on the percentage of viewer sessions connecting to Second Life with the Advanced Lighting Model (ALM), option enabled. While he was unable to give up-to-date stats during the TPV Developer meeting, he did reveal that the Lab has been looking at how the different classes of GPU perform with and without ALM enabled.
While the stats revealed lower-end GPU suffered significantly with ALM enabled than with it off (not unexpected) and mid-range GPUs showed little difference either way, they indicated that what the Lab refers to as “class 5” upper-end GPUs (e.g. ATI Radeon HD 7800, 7900, 8900, 8950 + similar, nVidia GTX 460/460SE, 465, 550TI, 580, 660/660TI + similar) actually performed better with ALM enabled, a result Oz admits to having “surprised the heck” out of him.
A new stats reporting system has recently been implemented by the Lab and Oz hopes to be able to use it to provide a far broader set of reports on viewer use, etc., and make them available to TPVs in the near future, which will include breakdowns similar to the above.
With thanks to Pantera for access to the video of the TPV developer meeting.
* Update, August 24th: I’ve been informed that as a result of this request, the Firestorm team will be clamping the upper limit for MeshMaxConcurrentRequests to 64 in the next release.
Inara Pey: Living in a Modemworld 
Not happy with the group ban idea, if that means the can block access for 1 group to a whole sim. That would mean that some mis assumption. or 1 person can screw it for 100’s of others..
LikeLike
The capability isn’t about banning groups from regions. It’s about banning troublesome individuals from groups with open enrollment, and is a response to JIRA SVC-8127. While it can be misleading, “Group Bans” has become the common shorthand in referring to it.
I generally include a link to the JIRA in my updates, but didn’t in this case as the update was so brief. However, you can see full details on the project and progress by using the Group Ban Lists tag link at the bottom of the article.
LikeLike