Comments on: New Timebase

Carl Sassenrath, CTO
REBOL Technologies
25-Apr-2007 17:47 GMT

Article #0088
Main page || Index || Prior Article [0087] || Next Article [0089] || 11 Comments || Send feedback

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.


>> 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.


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:

  1. 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).
  2. QueryPerformanceCounter may not exist on older hardware. So, #1 may be required if that condition is detected.
  3. Regardless, we assume the CPU overhead of whatever method is used is extremely low.



Brian Tiffin
25-Apr-2007 15:28:48
I'm not sure where things stand with POSIX compliance now-a-days, but the POSIX realtime extension spec uses

clock_getres() for getting at clock resolutions. It exists in Debian 4.0, my direct knowledge stops there.

Jeff M
25-Apr-2007 23:27:30
While for general purpose scripting and most of what REBOL would be used for I would agree, increasing the resolution only helps the programmer - it can't hurt.

There are *many* applications where microsecond timing resolution can be extremely beneficial. If REBOL 3 is to be embedded as well (ie REBOL/Embed) then this becomes even more important as REBOL may be used from within C/C++ applications that are performance critical and could use such information.

Anton Rolls
25-Apr-2007 23:56:52
This seems good. I was just reading about QueryPerformanceCounter the other day.
Rob Lancaster
26-Apr-2007 6:13
You might not be able to guarantee Millisecond timer accuracy for a function like wait, but I'd be more inclined to make the time! resolution as fine grained as possible... You may be hooked up to a GPS receiver... or some kind of data logger...

However, If time! can have differing resolution on different platforms... are you going to need a system for adding percentage errors when combining time! from different platforms... off at a random tangent.

26-Apr-2007 12:27:59
Yes! Great decision. Couples the timing to the device rather than the system. This is very very good, IMO.
Anton Rolls
27-Apr-2007 1:57:10
You must have found this document:
Maxim Olivier-Adlhoch
28-Apr-2007 20:08:24
if REBOL is to interface with things like Audio or video systems which want to update at EXACT rates or precise moments, the most precise you can make it, the better it is :-)

if an external device (lets say a realtime HD I/O framebuffer) is actually precisely syncing using an external source, then timing precision becomes very important and a millisecond is not such a minute amount anymore

ex: standard video and 1080i HD work at 60Hz... this means you must be able to time yourself at a minum of 0.016666666... ... in this case a millisecond is drastic... after a second, your already jerking a frame... and we really perceive this everytime it happens.

obviously I don't expect REBOL to be creating or processing Graphics at those rates, but its timing to interface external libs, should be able to react AT some precise moments. if only to send calls smoothly.

Maxim Olivier-Adlhoch
28-Apr-2007 20:20:35
btw, thanks for putting this in the open source part, so those with bigger needs can fullfill them, when the moment comes. :-)
Rob Lancaster
2-May-2007 5:27:14
Percentage Errors indeed! What I was trying to get at was the problems of inferred accuracy when time! measurements from Rebols running on a variety of machines with different time granularities are combined..

 a: make time! 10.00001   ; from my pentium
 b: make time! 10.00      ; from my C64

add a b >> 20.00

Could be this be considered a little more safer? Maybe not mathmatically.. but engineering wise... If all measurements or other time! operation were conducted on the same machine... this wouldn't be an issue..

If I wanted the accuracy, then maybe...

add/extend a b
>> 20.00001

Jorge Acereda
6-May-2007 6:01:15
For Mac OS X you can probably use mach/clock.h.
27-Oct-2010 5:33:55
Rob, you may already know it, because it's year 2010 now, but anyway:
>> a: make time! 10.00001
== 0:00:10.00001
>> b: make time! 10.00
== 0:00:10
>> add a b
== 0:00:20.00001
>> a + b
== 0:00:20.00001

Post a Comment:

You can post a comment here. Keep it on-topic.


Blog id:



 Note: HTML tags allowed for: b i u li ol ul font span div a p br pre tt blockquote

This is a technical blog related to the above topic. We reserve the right to remove comments that are off-topic, irrelevant links, advertisements, spams, personal attacks, politics, religion, etc.

Updated 23-Mar-2017 - Edit - Copyright REBOL Technologies -