Multiple timers or master timer and listeners?

I dunno, a 10 minute timer could result in a 19 minute and 59 second difference between one light turning on, and another. And that's a pretty huge difference where sunset is concerned. (since the active part of sunset only seems to last about 10 minutes).

It depends wholly on your use of the lights. If you want 60 lamps spread across a sim, then running 60 timers, versus 60 listens.. I dunno, my money is on the listens being more efficient.

The main issue is whether you need to keep time or not. If you do need it to work like a swiss clock, then use the llListen method. If your application can handle some unevenness, use the timer method.

Personally I wouldn't want one light in my shop failing to turn on for 20 minutes.

Just struck by something that made me ponder.

Whichever method is used a script is (or scripts are) regularly checking for the suns position.

Given that the sun cycle is fixed (leaving aside overrides) doesn't it make more sense to just determine the current sun position once when the script starts and then calculate and set timed triggers for dawn and dusk?

Another question about timers. When a timer is set does that set an alarm for which the system says 'time to wake up' or does the script regularly check progress and keeps telling itself 'not yet... not yet....not yet... OK - NOW!'

In other words, does the timer continually use resources or is it dormant waiting for an external trigger?

Thanks
Rime

I don't think we _know_ how this works - this is sim internals stuff..

If I had to guess, or even if I just felt like guessing, I'd guess that when you set a timer in a script, the sim takes the current time, adds the interval you specify to that and sticks this in a sim-wide ordered list of timers along with a pointer back to your script. When the sim starts giving scripts cycles, it looks at the start of this list and fires the scripts timer() event if it's <= than the current time.

Seems to me that it couldn't be more than a 10 minute difference. Lamp A's timer runs just after the sunset, so it's light turns on first. Lamp B's timer runs just before it, so misses it this round and turns on 10 minutes later.

Whether a timer or a listen is more efficient depends on how listens are implemented. Based on the explation I read, the time taken per listen goes up linearly per object per line of chat. A timer, on the other hand, is something we've been doing in real-time code for any decades and we have some very efficient ways to do them. Now, LL might not be using an efficient algorithm.

I really think it's a bit of a toss-up, and I seriously doubt the difference would be measurable anywhere but in a very chatty place, like a club, and with lots of lamps.

In any case, I suspect the .002 ms of time per script regardless what it's doing is more significant than the actual runtime. However, I have no idea whether estate manager Top Scripts time includes the system overhead involved in processing posted listens.

The real way to test this would be to rez a zillion of them and measure things (like ping time between two scripts, using LM or chat, and estate manager Top Scripts time).

Good thinking!

Yes and no. There are quite a number of excellent timer implementation algorithms, with myriads of tradeoffs. In simpler schemes, the system keeps a linked list of posted timers, sorted in time order. It sets a hardware timer to wake itself up whenever the top element in the list is due to run. The disadvantage of this is the overhead for finding out where to insert a newly set timer in the list: if it's a linked list and there are 100 entries, it takes on average 50 tests. One solution to this is called a timing wheel. Imagine a wheel with 60 bins. Every timer that's due to go off in second 0 is in bin 0. Every timer that's due to go off in second 1 goes in bin 1. This reduces the size of the lists by a factor of 60, dramatically reducing the insertion time.

And things get more complicated from there. For example, the most common timers to enque are the ones with the shortest times (since they tend to run periodically at high frequencies). The timer wheel concept can be adjusted with this in mind, but I don't recall the approach offhand.

But they're all simpler than listens.

The above implementations are for real time stuff where there's no big granularity of time. SL has time granularity, and can optimize due to that.

For SL, it probably isn't necessary to have a hardware timer as mentioned above, because the sim already has an enforced timeslice of 45 frames per second (or less). So, for SL, it would probably be more efficient to simply, on each timeslice, simply eat up the queue of timers due to expire in this slice. That's what I'd probably do, and possibly using a variation of the timing wheel to reduce queuing time.

The real problem with timers isn't using them at all, it's how much you use them.

Multipy 3 numbers:
* frequency
* average amount of script time used per timer() handler execution
* number of instances (scripts)

That gives you the real cost of the timers. The system cost should be trivial in comparison.

That concludes today's lecture. There will be a pop quiz on Monday!

Oops: correction. If the server code uses a single linked list for all timers, then system overhead for handling timers (enqueing them), worst case, goes up with the square of the number of timers, and it could be significant.

That's mitigated by the fact that the most frequently enqueued timers are short, and I'm sure they'd search the queue from the front of the queue, so in practice it's far better than the worst case. However, if there are lots of scripts with relatively short timers ... hmmm, i'd have to do the math; it's still not order N-squared, but ... it's probably not as good as order N-log-N. For this kind of thing, you really want to be in order-N territory. If anyone wants that explained, just ask, and you'll get another damn lecture!

In any case, if there is a performance problem with system overhead for timers, its starting/restarting them, not executing the timed-out ones. That part is easy as pie.

mmm, pie.

strip one down, compile, then copy to all others, assuming the all have the same variables, (or read them from outside the script) they would now have shared code space. any that get recompiled lose the benefit.

a single check and a timer to determine sun-up/down times will NOT be feasible because script timers are subject to time dilation, and will progressively worsen in their message timing due to accumulated losses to time dilation (becoming later and later after the event they should be messaging about) unfortunately we can't set hard timers inside of SL (such as this is triggered at 12:00 GMT). it could probably be done by external sources (RPC, html push, flash animation trigger?)

also top scripts isn't going to tel you whether listens being sorted and handled by the sim are having a higher impact than the script timers, because the server side isn't included in that stat (FPS apparently isn't workable either, but I'm sure there is a server console stat that would work)

Hmmm - how about this approach?

Script initializes and determines current time using llGetTimeOfDay()

From this it determines how many seconds to sleep before either dawn or dusk and sets a timer.

Timer triggers and uses llRegionSay(...) to announce dawn or dusk
Performs another llGetTimeOfDay() to reset the timer for the next transition.

For lights on/off applications timing would not need to be that precise and setting the sleep timer at each transition would make the worst case scenario slippage through a Linden day. I guess waking every hour to perform a timing adjustment would add minimal overhead.

I really appreciate all the input on this and the ideas and insights are very educational.

Thank you
Rime

OK. I can do that much to begin with: from what Lear advised in the meantime, I figure all the extra llSetPrimitiveParams I'm in the habit of including beyond Seagel's essentials is so much BS anyways.


Damn. This ought to teach me not to drift off topic if nothing else does. The example about Seagel's sliding door script only uses a timer to determine how long it should stay open before closing again and that is activated by a touch flag so I guess it isn't that relevant to the issue under discussion. However going back to my attempt to summarise some conclusions on page one of this thread ...

My lights do use a timer to respond to llGetSunDirection but I'm somewhat confused here because my typical lighting system involves at least one visible 'light' such as a wall fitting or a side lamp and an invisible root prim which is the light source. Activating the lights involves changing the colour of the 'visible' light slightly and adding a small amount of Glow while the lighting effect is actually generated from the root prim somewhere nearby. So it seems that llMessageLinked is still relevant whether I put one switch in each linked set of lights or attempt to link as many lights as possible throughout the building to a single root prim controlling them all.

The lighting features vary - off the top of my head I think there are three different intensities. Would it perhaps be better to stick to the current system of individual linked sets of lights and try compiled versions of similar scripts?


I'm not a sim owner so I can't use Top Scripts. I guess I'm very much limited to an educated guess on what may or may not work best here.

Hopefully they at least use a heap-implemented priority-queue for timers. That makes a check for the next timer O(1) and both inserting and removing an element O(log N). As pointed out, further performance gains could probably be achieved using a bucket sort on the server frame number or something of that nature.

And if LL doesn't use such an efficient means of implementing timers, we can assume they eventually will in the ongoing quest to reduce lag, so plan all designs accordingly!

lesse, if memory serves SL daylight:night is 3:1 hours. you could cheat and use a precalculated set of times for sunup/down, and only increase timer frequency when it aproaches.... wallclock numbers would give you your basis for times. and then you check if the next preset time is within your double your next timer window, or reset the timer to be half or that down to a certain limit.... maybe 7.5 minutes? then ignore sun direction and just use wallclock comparisons.

you wouldn't even have to store the wall clcok times, just add 4 hours to each of dawn or dusk numbers, when they're triggered, and swap between checking which one is your next to use. and set them back at each RL midnight.

so timer would = (current time - next time) / 2 > 7.5 minutes. that should give both accuracy at the changeover, and reduced queing leading up to it.

my current best guess is a single timer object that region says the light status, and linking as many lights as possible to take advantage of link messaging and reduce open listens... or just say to hell with the sim, and use listens for all of them since we can only accurately count script time =X