Help to impliment an accurate timer

I need to script a timer that is accurate to 1/100 sec or better if possible to time a racing event. I have tried a looping counter and it seems to be good to approximately 1/15 sec.. If there are any previous posts on the forums that covered the issue I did not see them. Any suggestions would be appreciated.

Thanks, MOD

ever heard of time dilation?
With many physical vehicles and viewers you will get some and everything will be slower.
so, how do you even time that? Not at all, thats how!
Your second will slow down to 1/0.8 seconds quite often, the script can read that dilation, but not too accurate, and it will be slowed down with anything in its region.
Go, test your accurate timer in a public sandbox, they run at half speed most of the day.

//with
float time;
timer(){time +=0.001;
llSetTimer(0.001*llGetRegionTimeDilation())}
//you could calculate out time dilation (if the timer actually CAN be triggered this fast with 1.0 dilation) and get something nearly synced with your clock next to the screen, but any timed event on any sl region runs anynchronuous!.
//for that You could also run multiple scripts in parallel and calculate an average time passed, thats how we measure world time, with more than 3 atomic clocks.

time dilation isn't the only enemy, even at a tenth of a second in a clear sim you can see jumps in executing even short code... the script vm isn't all that reliable for constant timed execution at that scale...

you might try comaparing the last digit in GMT clock to get/check your timer

Note that at BEST server frames occur only 45 times a second. Your script thus gets a small fraction of 1/45 sec to run every 1/45 sec. So it's incredibly unlikely you'll get much better than 2/100 sec. You're not going to get events faster than that anyway, and I suspect checking on external state (e.g. llGetObjectDetails()) is going to likewise slow you down enough to make it not worth while. That doesn't keep you from faking the APPEARANCE of 0.01 sec accuracy, of course....

By accurate, I am really talking relative time. Example, from the same start time to the end times between two racers. Which finished first and by how much?

The answer remains the same, I believe. Events may be triggered any time in the server's 1/45 sec (at best) frame, and your script will execute at some other time in that frame. Unfortunately there is no function giving you the exact time the current event was queued for execution (not even sure that would be a feasible feature request). Again, that is best case, if time dilation is close to one and you get as much info as possible in one event or in one tight loop running for as long as the server gives you in a frame. There is also a minimum time between events of 0.05 seconds.

I think your expectations are a little unreasonable for the SL environment. It isn't the real world with fast hardware. It is a time-sliced, network-based simulated world that has serious difficulty with precision. **shrug**

I did some further searches and it looks like llGetTimeStamp will give me decimal seconds out to 6 place.

True. It's just no guarantee of accuracy in timing in-world events.

Like Heewee said, you have to ask yourself -- exactly *when* will this six-digit-accuracy timestamp be generated... when you asked for it? or at some other time quite close to it...

There are 2 options for using this as a timer... neither of which relates to real world timing... but may solve your in-world comparison issues...

you can have a single "event timer" script running in the event sim, which gets a notification from each "contestant" to trigger the call, or each contestant could trigger a start and stop event allowing you to do some subtraction for "elapsed" time...

For all the reasons previously discussed, your elapsed time will probably NOT match real world timings of events... but if each of the contestants is subject to the same "time distortions", then the "shorter" elapsed time could still be "accurate" as an indicator of who "finished" first, second, third...... you still have to figure out how to deal with the fact that "simultaneous" start notifications are tough to accomplish.. or that notifications to a single event timer are not neccessarily handled by that timer in the order they were "sent" by contestants...

I think what I would try is an "elapsed time" measurement on-board the contestant.. with some form of adjustment to an event timer....

so event timer calls GetTimestamp....
sends start notifications....
elapsed timer starts on contestants...
finish triggers stop elapsed timer event..
subtract start time from finish time for elapsed time...
adjust start time discrepancy between event timer and contestant elapsed time startup for each contestant...

either compare adjusted finish times... or rely on elapsed time...

On the tangential subject, there is a difference between precision and accuracy. Your digital bathroom scale might report your weight precise to two tenths of a pound but still be an imaccurate scale if you really weight three pounds less than what it says.

Floating point arithmetic in a computer is normally done using a binary/base 2 number. It can represent the decimal/base 10 number 0.5 with complete accuracy, but cannot accurately represent, say, 0.4. It approximates it. The binary to decimal (string) formatted takes this into account and makes it look like 0.4 of course.

The subject is very deep. People specialize in the creation of math libraries they try to balance between speed and accuracy. That useful dinosaur COBOL did its arithmetic in base 10 because it needed to be accurate for some limited precision (say, two fractional digits).

All this is to say that a timer that gives you 1/1000 precision might be accurate at best to 2 seconds! With light server load that can be more accurate. Sand in a mechanical stopwatch affects it's accuracy but not it's precision.