interested in absolute time, rather than a way to measure the duration.
Win32 API
c++
views:
176answers:
7
A:
There is something in performance counters that has a 1ms resolution IIRC.
TomTom
2010-03-11 15:10:45
NkyN wants the wall clock time. QPC doesn't give you that.
John Dibling
2010-03-11 15:14:34
That has a "precision" of 1ms, I'm not convinced it has an "accuracy" of 1ms. Call it in a tight loop, and when the returned value changes, see how much bigger it is than the previous value.
Steve Jessop
2010-03-11 15:19:18
-1 Even though the SYSTEMTIME struct features milliseconds it is by no means accurate to 1 ms.
Paul Sasik
2010-03-11 15:19:21
+5
A:
You would need special hardware for that. Even though Windows APIs report milliseconds it's not exactly accurate as per this discussion:
Most intel pentium base PC's (I'm not sure about others) have a timer chip on the motherboard that has a 1.19318166667MHz counter.
The counter counts down from N (by default N=65535) to 1 at the rate of 1.19318166667MHz. The system timer interrupt is generated when the counter rolls over from 1 to N (zero never occurs). Note the system time is updated by this interrupt.
If N=65535 then the system timer interrupt is generated (1.19318166667/65535*1000000)=18.2 times per second. This equates to every 54.9 milliseconds.
This grainularity is inherent in most PC's in use today.
Paul Sasik
2010-03-11 15:15:03
My experience is that on modern computers, the accuracy is 16 ms, but not 1.
SkyN
2010-03-11 15:34:06
Good points SkyN and OldFart. Things change and "modern" is a relative term. The accuracy will be 5ms in 18 months.
Paul Sasik
2010-03-11 16:16:55
I'm curious now guys -- the .Net DateTime structure is granular down to ticks (1 tick= 100 nanoseconds = 10,000 ticks in a millisecond). I have used the tick count before to measure performance. If the resolution of the highest resolution timer on the PC is around 10ms, then is there any value at all in measuring time in ticks? (I'm not talking clock time now, but duration measurements)
JMarsch
2010-03-11 17:28:28
@JMarsch. High-resolution counters use different mechanisms. In principle, this is a value you can read straight off the CPU telling you the number of [small time interval]s which have passed, as opposed to a timer interrupt that fires every [large time interval] and updates the system time. In practice I don't know whether that's exactly how it's done. Why doesn't GetSystemTime add an extra, fine-grained term calculated from the high resolution counter? I don't know, if I had to guess I'd say historical reasons.
Steve Jessop
2010-03-12 02:02:04
+5
A:
You'll need hardware for such kind of absolute accuracies, like a GPS Radio clock. You will also need to write device driver level software, user mode programs cannot nearly respond fast enough to time something down to a millisecond. In general, Windows is not the right kind of operating system for this.
Hans Passant
2010-03-11 16:10:09
A:
If you want accuracy, you should check out NIST, National Institute of Standards and Technology. They have software that allows you to get the time from their servers. It has high accuracy and resolution. This is also the time standard used by GPS receivers.
However, you may not be able to get the time at a high frequency, due to network traffic and irregularities.
Thomas Matthews
2010-03-11 17:19:46
A:
timeGetTime was designed for use in media playback, so it is more accurate than the GetTickCount() function. It's not calibrated to Clock time however.
To get clock time accurate to the millisecond. You have to get the clock time, and also timeGetTime or QueryPerformanceCounter at as close to the same time as possible. Then you can make successive calls to timeGetTime etc, to get the number of milliseconds that have elapsed time from the known clock time.
Be warned that timeGetTime wraps around every 47 days ...
John Knoeller
2010-03-12 10:43:54
+2
A:
What you have to do is correlate the time of day with a value of an offset counter, and together with the frequency of the counter you can subsequently in your application quickly calculate the absolute time.
For a single core host not on power management and with a stable TSC using RDTSC would be the fastest, but you would have to determine the frequency yourself, typically by running a fixed time loop of say 5 seconds and measuring the difference.
The HPET device was created to overcome deficiencies of the TSC with multiple cores, hyper-threading, and power management causing variable clock rates. HPETs are only available in modern hardware, they have their own counter and programmable frequency and must be read similar to the TSC. The cost is more expensive, about 500ns though.
Windows provides the functions QueryPerformanceCounter and QueryPerformanceFrequency to handle this all for you, it will automagically choose the APIC or HPET device and use the TSC to interpolate values.
Steve-o
2010-03-12 10:56:14