Thread: millisecond precision measuring in C

Please note: Just because something has nanosecond resolution does NOT mean it is accurate to the nanosecond and/or that you can call it millions of times a second and get reliably-spaced and perfectly timed actions occuring on those intervals.

I'm believe there is a big difference, in terms of resolution, between passive and active timing.

By "active timing", I mean if you use a callback style function ("do this in 100 milliseconds"), or a sleep() style function, it will probably not be accurate beyond a latency of 1/100th second (10 ms) because that is the latency of scheduler. What that means is, this is the smallest interval at which the the OS can promise anything to user space applications.

By passive timing, I mean if you use a "get the time now" type function at points A and B, the difference between them might well have a microsecond accuracy, because this can be reported very simply based an internal count of processor ticks, which is a product of the frequency, which is constant and very very high. However, the value of this theoretical, because it all takes place within the context of scheduler latency. Eg, a duration of 2.5 ms might be accurately measured, but your program is still stuck running at the latency of the scheduler.

For example, if passive timing functions really are more accurate, a clever person might say, "Well I will write my own callback timer" by using a "get the time now" in a tight loop until X microseconds have passed. The most obvious problem with this is, that amounts to an active sleep which requires the processor to do nothing but count (very, very bad; this locks up a single core); the perhaps less obvious problem is that the events which hinge on this measurement are still managed by the scheduler and hence, subject to its latency.

So, you can in theory observe things at a much higher resolution than you can cause things to happen. You can observe this if you passive time a nanosleep() or callback style function:

Code:

get_time_in_microseconds(); // point A
sleep(1 millisecond);
get_time_in microseconds(); // point B

When you subtract A from B, the difference will be a lot more than 1 millisecond. That (passive) measurement is accurate, indicating that the sleep() call is not.

If you keep factoring the duration of the sleep up, you can find the effective latency -- around 10 ms, B-A will be very close to the amount of time you asked for. So when you are trying to make something happen at a given interval, don't bother asking for durations that are not a multiple of the latency.

MK, I think you can do better than 10ms for high priority processes, which I guess is how for example low latency audio works with a "soft real time" mode. There are some interfaces capable of ~1.5ms round trip latency, ie the delay for an audio signal to go into the interface pass through the system and hit the output again. That will of course vary somewhat between OS's, drivers and so on.

Re, passive timing, a new complication is also that the clock can vary depending on work load on new intel cpu's aka turbo boost.

Edit: Still the argument definitely stands for µS accuracy.

Originally Posted by Subsonics

Re, passive timing, a new complication is also that the clock can vary depending on work load on new intel cpu's aka turbo boost.

Okay but I'd equate that with slowing time down at a quantum level, so we should all still be safe . If you can't time time, then where are you?