Simon Linden has posted to the Server topic area of the technology forum about a new SL server feature, “region idling” which commences today, Wednesday 16th May.
This will see those regions that do not have any avatars either in them or camming into them to lower their frame rates and script processing, thus reducing their load on their host CPU. This should in turn improve the performance of the other regions running on the same hardware.
The idling itself should be entirely transparent to users, with the region immediately returning to “full speed” should anyone enter the region or cam into it. However, Simon does warn of a possible caveat to the transparency:
We expect this feature to be totally transparent to users. Residents will not see or be on regions that are idling. Scripts, however, may observe the effect if they are using the llGetRegionTimeDilation() function, and may require fixing.
There are some additional points to note with this capability, which are addressed in an FAQ also posted to the forum. These include:
- Regions are not turned off or shut down. They merely run at a slower frame rate when nobody is there. They will appear exactly the same way as before in search, the world map and other Second Life features
- Region idling cannot be manually disabled for a region
- Any scripts that use LSL network functions will suspend region idling for a short period of time to allow them to function normally. This will allow scripts that connect to outside services via email, http and xmlrpc to run as expected.
The roll-out of the function will commence with the Blue Steel release channel, and will then be progressively rolled-out to the rest of the grid in the coming weeks. Anyone suspecting region idling is having an adverse effect on their region is requested to file a JIRA (no specific project given), providing clear information on the problem and the exact times it happened.
Related Links
- Region Idling forum post
- Region Idling FAQ
- Server release information (week commencing 14 May 2012)
Inara Pey: Living in a Modemworld 
Anti-Idling Devices for sale on SL Marketplace in 3… 2… 1…
LikeLike
LOL was my first thought exactly . quickly followed by the fact that 30+ hippo rental boxes, probably 60 networked vendors, plus a few other items I use should keep my sim in perpetual motion.
but really I also imagine sims have plenty of of time to rev up during the tp region handshake.
LikeLike
My home land on the Mainland will never go idle due to a couple of (properly registered) bots.
All in all this seems like a good idea, especially since LL insists on cramming 8 regions / server the last time I checked.
LikeLike
I’m hoping the up-ramping will be accompanied by a whupp-whupp-whomp sound effect similar to the sound of office air-conditioning kicking on. Or maybe the doppler-effected sound of a car screaming past?
LikeLike
I presumed they pretty much did this already. I wonder if this also means “more sims per server”?
LikeLike
It doesn’t lend itself to adding more sims, since there’s no way to know whether all of the regions would be populated – this is really just about improving performance on regions where there are people. It’s just a good optimization, and something the engineers pitched after looking at a lot of server logs.
LikeLike
@Charlie
(Looks through Xenserver, Cloud and virtualization notes… GACK!)
I’ve been pondering Simon Linden’s original statement and responses for a while, and I’ll grant him that there’s the potential for performance benefits if homesteads are still stacked 4 per core, because that means unpopulated homesteads will be throttled and free up resources for populated ones.
However, when it comes to full sims, those are supposedly running one per core and core-locked, so when an unpopulated CPU-neighbor is throttled, that shouldn’t affect the other sims on that CPU because they can’t multithread across the free resources on other cores on that CPU.
Simon’s statement that there may be slight benefits if that throttled sim had the system resources running on it, which means those can run unimpeded, but that demonstrates a problem with the architecture that LL uses for resource management… if you have a resource-hog land on the core that runs the OS and other system resources, you’re screwing everybody else on that CPU. (I’m hoping that as 8-core systems roll out, they make an effort to region-populate the core running the OS last, or with regions that are historically low density.)
I feel that the benefits to the customer for this move are minimal, and instead this is meant to reduce resource consumption. Whether it’s meant to reduce power bills for colocation/datacenter, reduce numbers of servers needed to reduce footprint/cagespace… it looks like a cost reduction/profit increase move.
-ls/cm, wackadoodle
LikeLike
I found it kind of annoying that, instead of any of the top-level announcement areas, where it would have been most visible, it was put down in the forum areas where it is most likely only to be seen if another user tells you about it.
That’s hardly the best way to deliver and manage *any* message.
LikeLike
Totally agree; just getting awfully tired of beating that particular drum, sadly.
LikeLike
And here I was mentally celebrating the fact that it was an official Linden post at all, not some Tweet or unofficial meeting comment.
I agree though, it should have been more obviously posted.
LikeLike
There are several things looming, such as this idling and the Pathfinder system, which have the potential to interact badly with existing content. I don’t feel much scared by idling (something to think about: with the delayed Direct Delivery rollout: how will it affect the old Marketplace Magic Boxes still in use?), but the necessary support structures for Pathfinding could affect every structure out on the Grid. I can, if they bother to make clear explanations available, sort out my own buildings and doors, but with all the Linden Scenery out there, I just hope somebody has bothered to talk with the Boss Mole on this. And I have seen stuff which seems to have been placed by apparently dormant resident accounts.
LikeLike