Bandwidth is a problem right now. Those using capped services and those having ISP’s with a strict abuse ToS are supposedly running into problems.
The Magnum release channel seems to suffer the most. The worst case is when approaching the SW corner of a region that has 3 adjacent regions. Large draw distance aggravate the problem.
This problem is being worked on. See JIRA: SVC-8124 – Excessive “ParcelOverlay reliable” messages sent by regions since last rolling restart (2012-08-08). This not a completely pertinent item but discussion about the problem is ongoing and the flood of messages does effect bandwidth used.
A more on point JIRA is: VWR-29499 – Use of Internet bandwidth exessivo. [sic] But it is referred back to the previous item. The misspelling makes it hard to find via search.
Some are seeing the rate stick up around 2.5mbps.
Andrew has found… or the Lindens have, is probably more accurate… the problem and are currently rolling a fix. It should be in place before the end of the day. It may take a day or two for count numbers to correct.
The problem is in a backend side server that calculates dwell time. Fixing it fixes the problem and nothing has to roll to the main channel.
There goes Darrius’ theory.
Now that Havok 2012.1 is running across all channels region crossing are supposed to be better. To some extent they are, but in general they seem to have degraded for vehicles, planes, cars, boats, whatever.
Most of the Scripting-Server Meeting was consumed discussing the topic.
A factor in crossings is server location and which server adjacent regions are in. Some weeks ago the Lindens made an effort to get adjacent regions in the same server or physically adjacent servers to reduce network traffic time. It made a significant improvement in region crossing performance.
The consolidation of the 3 data centers into 2 has disrupted the organization of the regions and server. Once the consolidation is complete another organizing pass will be made. The consolidation should help some too, or at least so I think.
The roll out completed. This is mostly a configuration change roll out. None of the Lindens in Scripting/Server are knowledgeable on the details of what it is. Simon Linden says, “These are just OS and low-level service settings and no hardware changes are made with this update. We’ve been doing some hardware shuffling recently to balance the colos better, but that’s not part of todays’ update.”
So, we should little if any changes from today’s roll out.
This channel has a pile of bug fixes that have been in the QA queue for a long time.
A few people are seeing SVC-8146 – llRezAtRoot() does not set correct parameters (for sale) on rezzed object in Second Life RC Blue Steel 12.08.03.263047. Kelly linden said, “I have a fix for that one. it is a rare corner case though: it requires that the last person to rez the object in world be different than the owner of the rezzer.”
I haven’t run into it.
Kelly announced two new features that were not in the initial release notes for Blue Steel:
There are a couple of features on Blue Steel that managed to miss the release notes. llHTTPRequest now accepts a new metadata option HTTP_CUSTOM_HEADER to set custom headers on outbound requests.
I’ll see about getting that into release notes and the wiki this week.
Also if a remote server returns an application/json response to an llHTTPRequest, the script will accept it instead of [throwing an] error.
Baker updated us on the Group Edit problems for large groups:
I moved my group management code completely to WSGI, which will use HTTP to serve the data. This will mean no legacy viewer support for the new version.
On the plus side, things are running splendidly, and I’ll be getting it hooked up to the back-end via a cap later today. Then I’ll be getting the viewer updated with the new data format.
He is hoping to see it move into QA/RC in 2 to 3 weeks. But there is also a viewer component and it is unpredictable when we will see it hit the viewer QA.
I’m pressed for time so I’ve touched the main points. More later.