New Timebase
Some parts updated 2-Nov-2009
To allow more accurate timing in wait, R3 uses a different timebase than R2.
In R3, we use the QueryPerformanceCounter() method of timing and a continuous delta time is computed during the event processing of the wait.
The resolution of this timing method is about 1 microsecond (.000001). You can confirm the resolution of timing by calling stats/timer in a short loop.
However, we set the current time resolution for multitasking context switching within wait to 1 millisecond (0.001 sec). You can still call wait with values less than that, but depending on the situation, the CPU is not guaranteed to yield the processor.
Examples:
>> dt [wait 1]
== 0:00:01.007747
>> dt [wait .1]
== 0:00:00.102422
>> dt [wait .01]
== 0:00:00.009587
>> dt [wait .00001]
== 0:00:00.000013
The slight variation in timing is due to operating system variations in multitasking response and overhead.
More
We can change this resolution if we need to, but I don't see the benefit because most operating systems are not real-time. Between device overhead and timeslicing, we are lucky to get within a millisecond at all. (However, I should note that the R3 event/timer design is much more efficient and streamlined compared to R2.)
The code that handles timing is in the open source R3 API, so it can be adjusted as necessary. There are a few items we will need to consider:
- An equivalent of QueryPerformanceCounter will be needed for non MS systems such as OSX, Linux, cellphones, etc. (At worst case, we can use tick time as in R2, which is only about .02 resolution).
- QueryPerformanceCounter may not exist on older hardware. So, #1 may be required if that condition is detected.
- Regardless, we assume the CPU overhead of whatever method is used is extremely low.
11 Comments
| 
