A good time to quit?

well I've been playing around with throttled timers, and while I can keep precise timing ( very important for this)over a very wide range of sim dilation using various tricks, and changing to states that use simplified (but not as pretty) effects I had another thought

when's a good time to just quit throttling the timer?

currently I can get precise timing as low as .25 dilation... but do I really want to go that low? if I understand correctly dilation is a percentage of normal operations that SHOULD occur within a given time frame so at .25 it's only handling 1/4 of the operations that should occur within a given frame of time, effectively making everything take 4 times as long to execute, that's pretty slow

and does this affect built in delays? or are the delays in hard time instead of dilated?

when's a good point to just pack it in and let the sim try to catch up?

on a related note, what's a good script perf number for a low lag constantly running object?

I know opinion will vary on both of these questions, so if you have one, chime in, I don't mind comparing differing views =)

I think that entirely depends on the application.

I've been doing real-time and related programming for 3 decades now, and I'm confident that there's no simple answer to that question.

application is real time accesory, non critical, may be restarted on touch

need to add switching warning code into the start, currently it start in maximum (assumes dilation > .85) and adjusts each period

I just want to be sim friendly, beacuse with the throttled timer, it goes off more often (but with less instructions) as the dilation ratio increases...(I'm trading pretty movement for accurate timing by using a less granular movement, so knowing if delay times are affected by dilation helps also).

I know many makers shut down constant running polls if the sim dilation ration is bad... what do you consider a break point?

::bump and beg::

this is me pleading for input

I have no idea how to test if built in delays are hard time, or affected by dilation

and I'd really like to know what people think is a reasonable limit re dilation and continued functioning

maby you can use get and reset time and a external source (like atomic clock)

Osgeld has an excellent point, depending on the nature of the desired behavior.

I can't answer the factual question, and I don't have nearly enough info to address the question of judgement.

For very simple things where accurate timing isn't important, I wouldn't bother trying to compensate for dilation at all. And even with all the facts, the answer might be "it depends on what the customers might care about", or a cost/benefit tradeoff for you as the maker.

Sorry, no easy answers. The factual questions are testable. Positive answers ("Yes, dilation can affect these functions" would be definitive. Negative answers would not be, since there may be unidentified factors.

/me is confused:
I already have a method for getting and keeping acurate timing, (in this case important, normally I wouldn't care so much)...

just the technical Q: of how function delays are handled (and it's likely no one knows offhand) and the opinion poll on sim lag

/me shrugs:
oh well, we'll call it a dead topic

Try sending Kelly Linden a query about it. Alternatively you could post the question to sldev. If neither can help then you are definitely SOL.

According to everything I have read, the delay seems to be simply a sleep of the appropriate length. Basically:

llSetPos(myPos);

is equivalent to:

llSetPosWithoutDelay(myPos);
llSleep(0.2);

http://www.lslwiki.net/lslwiki/wakka.php?wakka=ScriptDelay



Now, if you are asking what the technical aspects of llSleep are, I think I would say that llSleep only guarantees that the script will be inactive for a MINIMUM of the specified time. It could be longer, since all it does is takes the script out of the "ready/running" queue, puts it in the blocked queue for the specified time, and then moves it back to the ready queue when the time expires. As such, you are only guaranteed the minimum. The maximum could be anywhere from the minimum to sometime past the 12th of Never.

hmm according to the link for llMinEventDelay if a timer is fed less than default DELAY (.1) it will still only trigger every .1 seonds (even if timer is specified as say llSetTimerEvent(.05)....

not sure if that info is out of date, or it actually still behaves that way, in which case timer throttling needs to be adjusted in my script to allow finer control via that function.... must devise a test for this....

I know that llSleep seems to obey dilation (which would be why it gives inconsistant results with a minimum of specified sleep time), but I can't seem to come up with a good test to see if built in function delays obey the same rulels... I'm guessing they do, but w/o a way to specify dilation, I can't test it, and if it doesn't obey the same rules, my throttled timer could actually work MUCH more effeciently at higher dilation ratios than currently coded...

lacking input of the other part of the question, I've decided to kill it if dilation hits .25 (script operations take 4 times their normal time for operations at this point, assuming dilation is a linear percentage, which may be wrong, but I can't find anything to refute/clarify this)

@ Jesse:
Not On SLDEV ( I know I should be, but I check e-mail maybe once a week? ) I may bug Kelly about the delay question, assuming I get over the fact that most of my questions to LL seem to have no answers