millisecond precision measuring in C

What techniques / methods exist for getting sub-millisecond precision timing data in C or C++, and what precision and accuracy do they provide? I'm looking for methods that don't require additional hardware. The application involves waiting for approximately 50 microseconds +/- 1 microsecond while some external hardware collects data.

thanks for all (-:

There's nothing in the C standard that's going to give you what you want, so the answer will vary depending on what you're programming on. First off, if you're using a general purpose OS, you might want to reconsider if +/-1 uSec resolution is required because many won't be able to guarantee it.

You can look into doing a simple busy loop continually checking the results of e.g. gettimeofday() or QueryPerformanceCounter(). Even if these return values in uSec or nSec it doesn't mean they have 1 uSec resolution, though. You could also look into using timers of some sort (either through OS functions or hooking into timer interrupts explicitly).

But again, without knowing more detail it's hard to give a real answer.

You could use the routines in <sys/timex.h>

Or, find your CPU cycles and then calculate uSec by using your processor's hertz rating.

in linux/unix use clock_gettime.
clock_gettime(3): clock/time functions - Linux man page
on windows use QueryPerformanceFrequency/QueryPerformanceCounter

for processors that have them, these functions use the high resolution timer register from the CPU. more or less nanosecond resolution

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.

Originally Posted by ledow

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.

Exactly, in a typical desktop OS the kernel has much more to do than to attend your process.

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.

Originally Posted by MK27

this is the smallest interval at which the the OS can promise anything to user space applications.

unless you can convince the operating system to provide real-time scheduling to your process. Windows has an option for that in the task manager, and a linux kernel can be built to provide real-time scheduling. it's not uncommon to do this for audio and video applications.

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?

Originally Posted by MK27

If you can't time time, then where are you?

Well you could still count "ticks" and ignore converting it to time, that would still provide a common ground for comparisons and be more accurate, but unfortunately not tied to absolute time.