[slscripters] Timer event moderation

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[slscripters] Timer event moderation

Void Singer
With the upcoming addition of region idling I thought I'd get solid
confirmation on how certain events/functions are handled within LSL so
that any notations to the wiki could be made on expected behavior....

it was my understanding that the Timer event (and sensorRepeat, and
sleep) were essentially tied directly to frame rate... ie ceil(
seconds / optimal-frame-rate ), and then executed on a countdown when
it reaches zero.

others have proposed that that it's (timeNow + seconds) and checked vs
the system clock each frame to see if it's been exceeded....

both have vastly different expected behaviors when frame rate
changes... the former scales dilation effects directly with region,
and the latter self corrects to real time.

there's a third possibility where instead of optimal frame rate, the
current frame rate is used, but it seems nonsensical to base a
regulated event on a variable.

so Kelly, how is this actually set up on the back end? and as silly
question, is it the same for all these events/functions (possibly
including function and event delays?) across both LSO and MONO?
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: [slscripters] Timer event moderation

Stickman-2
> it was my understanding that the Timer event (and sensorRepeat, and
> sleep) were essentially tied directly to frame rate... ie ceil(
> seconds / optimal-frame-rate ), and then executed on a countdown when
> it reaches zero.
>
> others have proposed that that it's (timeNow + seconds) and checked vs
> the system clock each frame to see if it's been exceeded....

http://wiki.secondlife.com/wiki/Beta_Server_Office_Hours/Minutes/2012-05-17

Best official word I got out of Simon Linden in the last beta office hour was:
[15:24] Simon Linden: timers are a weird mix of real and SL time

Simulation/script office hours are tomorrow (Monday) morning at 9am SL time.
http://wiki.secondlife.com/wiki/Simulator_User_Group

If anyone can make it (I don't believe I can) and can ask about this
subject, that would be ideal.

Specific information about a list of functions that temporarily
un-idle a region are also useful, though that was partially provided
in the beta usergroup.

[15:14] Stickman Ingmann: Is there a list of LSL calls that spin a
region back up?
[15:15] Maestro Linden: the short list is LSL email, HTTP, xmlrpc, or
anything that triggers the dataserver event

And for completeness, any physics actions (and script keyframe
animations) will also be slowed down to about 1/5th their normal rate.

Those learning about region idling for the first time should check out
these two threads:
http://community.secondlife.com/t5/Second-Life-Server/Region-Idling-coming-to-Second-Life/td-p/1535485
http://community.secondlife.com/t5/Second-Life-Server/Region-Idling-FAQ/td-p/1535497

Stickman
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: [slscripters] Timer event moderation

Eloise Pasteur
It's worth remembering in your consideration that as a sim starts overloading (being unable to maintain it's 45fps ideal rate) the first thing that is done to try and maintain the fps is to reduce the amount of script calls executed - in effect script time runs slow.

Either method you've suggested will give you a reasonable timer event in a happily working or maximally loaded sim. Either will give odd results in an overloaded sim when compared to an external clock.

Say you have a 30s timer. If the sim is running OK, you do 30*45=1350 script-frames tick by, then the timer triggers. If the sim is overloaded in the middle of that 30s and for 10s the script-frames run at half speed, you'd find the 30s timer actually fires after 35s. Although it's been a long time since I looked specifically at this, this is my understanding of and my (dated) observation of how it works, or close enough.

If the timeNow+seconds model is used, having a spike of overload in the middle of the timer wouldn't slow the timer event, but if that spike is moved to the end, then whatever queuing system in the threads is used kicks in and essentially the sim doesn't (necessarily) check if the current time is greater than the target time in any given frame, so it will run late, although not necessarily predictably so.

Although the first system may seem odd, it makes the misery spread itself evenly over scripts in the sim, and spreads the recovery too, without suddenly sparking another overload as all those timer events suddenly fire at once. It also helps explain why sims that are down for extended periods delay timers (I see this all the time with items that report every 24h and will suddenly report late one day after, for example, a sim restart for an update), the script doesn't count frames while the sim is down, starts when it comes up and so reports after 24h+downtime. Thanks to the way I wrote it, it then corrects the next day as expected too. if it used the timeNow+seconds approach you'd expect it to only delay reports when the sim is down at report time and that's not seen.

El.

On 21 May 2012, at 01:39, Stickman wrote:

>> it was my understanding that the Timer event (and sensorRepeat, and
>> sleep) were essentially tied directly to frame rate... ie ceil(
>> seconds / optimal-frame-rate ), and then executed on a countdown when
>> it reaches zero.
>>
>> others have proposed that that it's (timeNow + seconds) and checked vs
>> the system clock each frame to see if it's been exceeded....
>
> http://wiki.secondlife.com/wiki/Beta_Server_Office_Hours/Minutes/2012-05-17
>
> Best official word I got out of Simon Linden in the last beta office hour was:
> [15:24] Simon Linden: timers are a weird mix of real and SL time
>
> Simulation/script office hours are tomorrow (Monday) morning at 9am SL time.
> http://wiki.secondlife.com/wiki/Simulator_User_Group
>
> If anyone can make it (I don't believe I can) and can ask about this
> subject, that would be ideal.
>
> Specific information about a list of functions that temporarily
> un-idle a region are also useful, though that was partially provided
> in the beta usergroup.
>
> [15:14] Stickman Ingmann: Is there a list of LSL calls that spin a
> region back up?
> [15:15] Maestro Linden: the short list is LSL email, HTTP, xmlrpc, or
> anything that triggers the dataserver event
>
> And for completeness, any physics actions (and script keyframe
> animations) will also be slowed down to about 1/5th their normal rate.
>
> Those learning about region idling for the first time should check out
> these two threads:
> http://community.secondlife.com/t5/Second-Life-Server/Region-Idling-coming-to-Second-Life/td-p/1535485
> http://community.secondlife.com/t5/Second-Life-Server/Region-Idling-FAQ/td-p/1535497
>
> Stickman
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters

http://educationaldesigns.eloisepasteur.net/
http://eloisepasteur.net/blog/




_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: [slscripters] Timer event moderation

AnnMarie Otoole
I see a problem with programs using real time monitors.  I use Unix time
monitors to escape from stuck "while" loops.  This will require
modification and break 1,000+ customer vehicles until I can get them
updated.  It could break many objects relying on Unix time to check
progress etc..

Will the Object Return timer be slowed down in proportion ?
If scripts and physics slow down in proportion it appears my vehicles
would run at 1/8(?) speed if they have no passenger but if no one can
see it will do no harm.  However if Object-Return goes at normal speed
they won't be able to cross many sims in time.

There are situations, too, where the TEMP_ON_REZ timer would also have
to slow down in proportion so they are not deleted before completing a task.

AnnMarie Otoole
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: [slscripters] Timer event moderation

Kelly Linden
Timers use real time in the following manner:

When a script gets its turn to run it checks if the timer has expired.
If it has then a timer() event is added to the event queue, and the
timer is reset. The extra time (from when the timer expired to when
the event was added) is subtracted from the next timer run. If there
is a timer() event already in the queue or currently running then no
new timer() event is added to the queue.

With region idling timers will work as before except their accuracy
will be reduced to the lower frame rate and their max rate will be
similarly reduced.

On 5/21/12, [hidden email] <[hidden email]> wrote:

> I see a problem with programs using real time monitors.  I use Unix time
> monitors to escape from stuck "while" loops.  This will require
> modification and break 1,000+ customer vehicles until I can get them
> updated.  It could break many objects relying on Unix time to check
> progress etc..
>
> Will the Object Return timer be slowed down in proportion ?
> If scripts and physics slow down in proportion it appears my vehicles
> would run at 1/8(?) speed if they have no passenger but if no one can
> see it will do no harm.  However if Object-Return goes at normal speed
> they won't be able to cross many sims in time.
>
> There are situations, too, where the TEMP_ON_REZ timer would also have
> to slow down in proportion so they are not deleted before completing a
> task.
>
> AnnMarie Otoole
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
>
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters