views:

95

answers:

4

Hello all.

How can I get the Windows system time with millisecond resolution?

If the above is not possible, then how can I get the operating system start time? I would like to use this value together with timeGetTime() in order to compute a system time with millisecond resolution.

Thank you in advance.

A: 

GetTickCount will not get it done for you, look into QueryPerformanceFrequency/QueryPerformanceCounter. The only gotcha here is CPU scaling though, so do your research.

Joel Clark
QPC is not what I want. I want the system time with millisecond precision, not a timer.
axilmar
Power saving (even just idle power saving) and Turbo Boost play merry hell with QPF. It used to be very effective, but with modern CPUs it's no good anymore.
Ben Voigt
A: 

Try this article from MSDN Magazine. It's actually quite complicated.

Implement a Continuously Updating, High-Resolution Time Provider for Windows

Kevin Gale
I do not want a timer, I want the system time with millisecond precision.
axilmar
Did you read the article? That what it is about! This guy did exactly what you are asking and shows how it is done including code.
Kevin Gale
You would think I would deserve at least one vote up for being the only one to provide a solution even if it is probably more complicated than people wanted to hear. :-)
Kevin Gale
A: 

GetSystemTimeAsFileTime gives the best precision of any Win32 function for absolute time. QPF/QPC as Joel Clark suggested will give better relative time.

Ben Voigt
Isn't there anything better than GetSystemTimeAsFileTime? the get-system-time functions have a precision of 10 to 15 milliseconds.
axilmar
That's the accuracy, not precision. And a call to `timeBeginPeriod(1);` will set the accuracy to 1ms.
Ben Voigt
Ok, it's the accuracy then (I always mix those two since in my language there is only one word that represents both). Is there a way to get the system time in Windows with 1 millisecond accuracy? I am using timeBeginPeriod(1), but the time is still returned with 10-15 milliseconds accuracy.
axilmar
A: 

This is an elaboration of the above comments to explain the some of the whys.

First, the GetSystemTime* calls are the only Win32 APIs providing the system's time. This time has a fairly coarse granularity, as most applications do not need the overhead required to maintain a higher resolution. Time is (likely) stored internally as a 64-bit count of milliseconds. Calling timeGetTime gets the low order 32 bits. Calling GetSystemTime, etc requests Windows to return this millisecond time, after converting into days, etc and including the system start time.

There are two time sources in a machine: the CPU's clock and an on-board clock (e.g., real-time clock (RTC), Programmable Interval Timers (PIT), and High Precision Event Timer (HPET)). The first has a resolution of around ~0.5ns (2GHz) and the second is generally programmable down to a period of 1ms (though newer chips (HPET) have higher resolution). Windows uses these periodic ticks to perform certain operations, including updating the system time.

Applications can change this period via timerBeginPeriod; however, this affects the entire system. The OS will check / update regular events at the requested frequency. Under low CPU loads / frequencies, there are idle periods for power savings. At high frequencies, there isn't time to put the processor into low power states. See Timer Resolution for further details. Finally, each tick has some overhead and increasing the frequency consumes more CPU cycles.

For higher resolution time, the system time is not maintained to this accuracy, no more than Big Ben has a second hand. Using QueryPerformanceCounter(QPC) or the CPU's ticks (rdtsc) can provide the resolution between the system time ticks. Such an approach was used in the MSDN magazine article Kevin cited. Though these approaches may have drift (e.g., due to frequency scaling), etc and therefore need to be synced to the system time.

Brian