Region Idling FAQ

[Simon Linden]

Region idling is a new technology added to the Second Life system that will help better share server processing power between regions that are busy and regions that are empty.   Here are answers to some common questions about region idling.

How does region idling help Second Life?  

Region idling will help Second Life server performance and stability by lowering the amount of computing power used by empty portions of the grid.   If the servers spend a little less time simulating parts of the virtual world where the are no residents, this CPU power can help busier areas.

When does a region idle?  

Regions will start idling when there are no residents on that region, or in adjacent regions looking into it.   The instant a resident teleports or looks into a region, it stops idling.

Is Linden Labs turning off my region?  

No, 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.

Can I disable region idling for my land?  

No.  Region idling will eventually be enabled for all Second Life regions.   If you believe region idling is causing issues for your land or content, please file a jira bug report with clear information describing the problem and the exact times it happened.

Is there any LSL support?  

The llGetRegionTimeDilation() function will report a high time dilation when regions are idling.    You can now pass “region_idle” into the llGetEnv() function to determine the current idling state on a region.

What about LSL network functions?  

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.

My region monitor object is telling me the region slow, what should I do?

In-world objects that use the llGetRegionTimeDilation() function will see increased time dilation during region idling.   This is to be expected.   The scripts should be updated and use the llGetEnv() function, passing in “region_idle” to see if the increased time dilation is due to region idling.

How is this being deployed?  

Region idling will first appear on the Second Life BlueSteel RC channel.   We will closely monitor these regions for issues as we do for any server update.  When we are confident there are no problems, it will be enabled on the full grid.

I found a bug caused by region idling.  What should I do?  

If you believe region idling is causing issues for your land or content, please file a jira bug report with clear information describing the problem, the exact times it happened, and why you think region idling is the cause of the issue.

[Celestiall Nightfire]

Hmm, just saw my email from Oskar and followed the links, and have now read all about the Region Idling..and it sounds good. 

*This* is the type of work that people are looking for...thanks...for looking for solutions to the in-world stability issues. 

 

Oh, thanks to Oskar Linden and team  : )

[Allen Kerensky]

Excellent idea and pretty decent sounding implementation.

[Tabby Fenwitch]

And how will this effect the breedables? Are we going to have to park ourselves on our land to make sure that the breeding cycle doesn't extend exponentially?

[WolfBaginski Bearsfoot]

Wouldn't that depend on how the breedable measures time?

I can't see that being answered usefully by a Linden. You need to ask the person who scripted the breedable 

 

[Stickman Ingmann]

Depending no how they did the details of region idling, and how the breedables were created, there could potentially be problems, but I doubt there will be. It all depends on the way the timer is set for the breedable, and how low the framerate gets. Once more information about region idling is released, you can contract the scripter of your breedable and ask them if it would be a problem.

My guess is that it won't be.

I posted some technical details on why, here: http://community.secondlife.com/t5/Second-Life-Server/Region-Idling-coming-to-Second-Life/m-p/1536199/highlight/true#M5460

[Dilbert Dilweg]

Hmm Very Interesting..

 

[Stickman Ingmann]

Short answer to breedables: They won't even notice if the region goes idle.

Long answer, Simon Linden explains here http://community.secondlife.com/t5/Second-Life-Server/Region-Idling-coming-to-Second-Life/m-p/1536577/highlight/true#M5464 that frame time is reduced to 8-10 frames per second. While he didn't answer all my questions, this information means that as long as your script doesn't try to call a timer() event more often than 0.125 seconds, most scripts probably won't even notice if the region is idling. This includes breedables.

If there is any breedable on the market that has a constant timer running at 0.125 seconds or less, I would recommend you do not do business with them until they improve their scripts. A breedable with a script that aggressive would be take up more resources than it should, and be a hinderance to a lag-free experience for everyone. Most of the breedables I've seen appear well made, and would not fall into that category.

[WolfBaginski Bearsfoot]

That is more or less what I figured.

Since this still depends on competent scripting, and on Linden Lab informing scripters in time for them to resolve any issues, expecting this new feature to get out there without problems is about at the same level of wisdom as betting on slow horses.

 

[Innula Zenovka]

How, if at all, will this affect timer events with a long interval?

I'm not all sure how timer events calculate the passage of time, but I've seen it suggested that it's based on execution frames rather than directly on the system clock, in which case that would presumably make the timer run slowly while the region is idling, thus throwing out timers that try to schedule things to happen every n hours or whatever.

But perhaps it doesn't work that way and my concerns are misplaced.

[Stickman Ingmann]

A timer tries to execute on the nearest frame closest to the real-time (not lagged time) equivilent. Someone was complaining in the scripting usergroup that a timer of 0.075s wasn't triggering every 75ms at all, but was wavering back and forth between 88ms and 67ms.

Since simulators normally run at 45 frames per second, each frame is around 22ms seconds long. (1 second / 45 frames = 0.0222 (repeating) seconds.) A timer can only execute when a frame comes up, which includes 88ms and 67ms, but not 75ms.

Thus, when region idling kicks in and you start getting 8.2 frames per second (frame time increases from 22ms to 122ms, with the extra 100ms being forced "unused" time, so 1000ms/122ms = 8.1967...fps) your timer only  has around 8 chances to trigger every frame. It'll get a little less accurate, and if you're calling it more than 8 times a second (every 122ms, or just 1 second / 8 frames = 0.125 seconds, or 125ms) you're going to end up not having the timer execute as often as you call it.

That is on a normal, unidled region, if you were able to call the timer more often than 0.05 seconds, such as 0.01 seconds, and frame time is 0.022 seconds, the timer would be trying to trigger more than twice every frame. In this case, the timer would start queuing and executing every single frame, but lag behind because it wasn't executing as often as you called it for. After one second, your script would have executed 45 timer events when you asked it to execute 100 events.

In the case of region idling, calling the timer more often than 125ms/0.125s does the same thing. The events queue up, and once it hits 64 queued events it will start dropping events. But will still execute every frame.

Thus, well written scripts won't be affected by region idling. Anyone who needs more than 0.125 seconds per timer event can just detect region idling and adjust their timer accordingly.

Physics will be affected by region idling. So will things like keyframe animation. Physics will run at roughly 1/5th the speed (8/45=0.1777..., 18%). It's possible to detected (llGetEnv()) when the region begins idling and compensate for this artificial lag if it's necessary to "keep the trains running on time." Just keep in mind that no one will be around to see it, and things will pop back up to speed within milliseconds (notably less than 100ms or one tenth of a second -- likely before anything even loads on the screen) of someone even getting close.

[Innula Zenovka]

Thanks.   I think I follow, but I'm still a bit confused.

If I call llSetTimerEvent(3600.0) at midnight SLT, are you saying the timer event is going to fire on the nearest frame to 0100 SLT on the system clock, no matter if the region has been idling between midnight and one AM (that is, it might be a fraction of a second out, but no more, and, even then,  only if the region is idling at 0100)?

 

[Stickman Ingmann]

Yes.

[Triple Peccable]

Excellent description, Stickman!

I hope it helps put the minds at rest of some of those who are so worried they want to opt out.

I would only add that I don't think multiple timer events queue up. If a timer fires and there is already a timer event in the event queue, another one isn't added. So the event queue filling up with timer events is one less thing to worry about in an idling region.

 

[Moon Metty]

Indeed, the event-queue can only hold one timer event.

Another detail: The timer event never triggers two consecutive available frames. The fastest rate possible is 45/2 = 22.5 events per second. This slows down further when the script engine can't handle all scripts in a single frame.

I can't imagine that can cause problems on an idle region, though.

[Stickman Ingmann]

If the non-consecutive frame behavior for th timer event doesn't change, that puts the limit on timer events up to 0.25 seconds while a region is idle. (244ms actual)

Less of a problem if timer events don't queue, but more of a problem if people expect the timer event to fire more often. Still, 250ms isn't bad at all. But having accurate numbers helps when designing things.

Thank you for the information, Moon. Much appreciated.

[WolfBaginski Bearsfoot]

What worries me about all this are the scripts which can only be edited by the original creator, and which will behave in unexpected ways.

I know of vehicle scripts which started misbehaving  several years ago, because of changes to the physics engine., which have never been patched by the creator.

 

[Flea Yatsenko]

What we need is an event which tells the script when the simulator has entered idling mode and when it has left it. If we don't get anything like that, we are going to end up with scripts polling region time dialation as soon as possible which isn't good scripting practice.

The best way to script around this is to save your script state with a timestamp, enter idle state, and when you leave idle state calculate how much the data should have changed between the time it went idle and the time it left idle state.

For example, if you have a breedable and hunger is supposed to grow by .1 every minute, you can either leave that in a timer, or you could wait for the region_idle event and save a timestamp. When you get the even which says region is no longer idle, you could grab another timestamp, find out how many minutes have passed, and then calculate how much hunger has changed.

If you have an animal which is supposed to move around, you could freeze it when idle state is detected and when the sim gets the event that it's left idle state, move it to a random position within certain parameters and you'd be good to go.

Without these events, we will end up with scripts relying on polling sim FPS as fast as they can, which isn't good at all.

Can we get some sort of LSL events which tell us when the sim has entered idle state and when it has left idle state? It would make scripitng around this a lot easier as opposed to entirely depending on the simulator to do it for us. There will be times when a script will be hurt by running at lower FPS and it would be better to just code around the fact it's going to happen as opposed to taking the unexpected behavior.

[Theresa Tennyson]

This is what SImon Linden said about that - I don't know enough about scripting to know if it would do what you want.

Is there any LSL support? 

The llGetRegionTimeDilation() function will report a high time dilation when regions are idling.    You can now pass “region_idle” into the llGetEnv() function to determine the current idling state on a region.

[Innula Zenovka]

---

Theresa Tennyson wrote:

This is what SImon Linden said about that - I don't know enough about scripting to know if it would do what you want.

---

The problem with that is you will need to keep on checking, all the time, to see what the time dilation is, or whether the region has started or stopped idling.   

What Flea is saying is that we need an event that fires when the region starts or stops idling.  

That is, in effect, we need to be able to put something in a script that tells the sim, "if the region starts or stops idling, tell me that's what's happened" rather than -- which it seems we'll have to do -- put in something that says, "keep on asking the region if it's idling or not".

[AnnMarie Otoole]

"Physics engine slows down" - What exactly does that mean?  Does vehicle impule have less effect so vehicles run slower?  My vehicles have speed governors that maintain desired vehicle speed.  In particular they ramp the accelerator up when needed to climb hills and decellerate to prevent over speed down hill.

Will sim idle be a problem?  If the vehicles slow down (distance covered per second) the accelerator will ramp up to (8 times? normal) to try and maintain speed.  If the sim wakes up they will take off like bullets.

In some sims the vehicles hve to maintain speed to cover the sim within object-return time.  Will object-return clock time be lengthened in proportion to the slow down?

AnnMarie Otoole

[Stickman Ingmann]

More accurately than "physics slows down" would be to say that "time slows down." Physics calculations won't change, they'll just happem about 5 times slower.  In many respects, this will appear the same to a region lagging.

Say you have a racecar that automatically runs around a track. If it runs an entire lap in one minute, normally, then if the region is idle it will run that lap in about five minutes instead. But odds are it won't end up flying off the track or something when the region idles. It's possible, but it takes a certain type of creativity to write something that would end up doing that. And it would be immediately visible as soon as the region started lagging at all.

Some vehicles can automatically compensate for lag. That is, they will detect if the sim FPS changes, and move "faster" so even though time has slowed relative to the physics simulation, the car moves at the same speed according to the external viewer.

Depending on how your vehicles are written, they could encounter the problems you suggest. Have you ever had a vehicle get auto-returned because the region it was passing through was lagging? If so, the same problem can happen in an idle region as well. If you've already encountered this problem and compensated for it, you've already made your vehicles region idle compatible.

[AnnMarie Otoole]

They do adjust for lag and terrain to attempt to maintain a constant velocity without sliding backward going up-hill or going too fast down-hill but since they are using distance travelled per (SL) timer second that should work OK.

But will sim object return time slow down proportionally?

Will Temp-On-Rez time slow down proportionally?

I use Unix time to check for vehicles stuck in a "while" loop involving vehicle movement due to obstructions, etc.  This will probably break them so I guess I will have to rework scripts to detect if the sim is idle and lengthen the time to exit.  This could break over 1000 customer vehicles until they contact me for a replacement.

BUT QUESTION:-

I heard that an http request will stop the idle status.  All vehicles log into an off-world data base after every sim crossing for tracking.  HOW long will the region stay active before returning to idle after an http request responds?

[Al Supercharge]

frame rate  -- for all I know  -- reduces the frequency a Viewer screen changes ? and what else? 

Anyway I can now use 

string IDLE = llGetEnv("region_idle");  

in a 10 second timer ( instead of llSensorRepeat ) to tell me if anyone is within range. Set all my birds and fish to NON-PHYSICAL and STOP RUNNING all scripts. Reverse it when IDLE in timer drops.

What do you reckon otherwise ? What does lower frame rate do to llMoveToTarget?

 

 

[RainO Tenk]

Total agree, the scripts overhead by polling for idle state all time would grow to serious amount, there needs be a kind of sim message send to an event which than can be used to trigger action or the complete things turns around clockwise and ends in lots more lag at no idle state, servers will have to work more and all the benefits from idling some would be eaten up by polling for state

 

RainO