[time-nuts] GPS message jitter (was GPS for Nixie Clock)
martin.burnicki at burnicki.net
Mon Jul 18 04:48:04 EDT 2016
Chris Albertson wrote:
> Can't you take care of this in the build system? I never go near
> Windows, the last version I used was Win 95. But on other systems I
> always use something like the GNU Auto tools cmake or whatever and
> part of the process is to check for the availability of each system
> call and library and then the source is built using what's on that
> specific machine. I'd guess that there is something like this in
> Windows. Is GNU Autoconf ported to Windows? If so then use
> QueryPerformanceCounter() if it is available. It seems much cleaner
> to that care of this kind off thing in the build process
The QueryPerformanceCounter() (QPC) call is available on all Windows
Versions since Windows NT. I'm not sure if it was supported on Windows
9x, though. The windows 9x versions were more like DOS with a graphical
QPC is implemented in the Windows Hardware Abstraction Layer (HAL). At
least Windows versions around XP were shipped with different versions of
the HAL DLL, and the Windows installer determined during installation
which version to use. The different versions used different timers on
the particular PC, and depending on the timer which was actually used
(TSC, HPET, PMTIMER, ...) the QPC call worked with different clock
frequencies and thus provided different resolution.
When Windows XP was current then current CPU types both from Intel and
AMD had problems with the TSC since the TSC clock frequency could change
when the CPU clock frequency changed due to power savings, and TSCs
might not have been synchronized across different cores in the same
This is why you could force Windows XP always to use the PMTIMER which
is part of the ACPI support chipset, and if I remember correctly the SP3
for Windows XP did this automatically to avoid problems with the TSC.
You can use the QueryPerformanceFrequency() call to determine the clock
frequency of the timer used for QPC, and the frequency typically tells
you which timer/counter circuit or the PC it actually is.
One important point is that the TSC can be read very much faster than
one of the other timers/counters since its just reading a CPU register,
while other circuits are part of the chip set and need to be accessed
via a peripheral bus.
Modern Windows versions determine much more reliably if the TSC can be
used without problems, or not, and use it, if appropriate.
Modern Windows versions (Windows 8 an newer) also provide some new API
calls which return the system time with higher resolution/precision than
original API calls.
For example, the original API call GetSystemTimeAsFileTime() only had a
coarse resolution of 0.5 to ~ 16 ms, depending on the Windows version
and some conditions. Now there's a new API call
GetSystemTimePreciseAsFileTime() which always provides 100 ns
precision/resolution. Similar with some other call for which there are
"Precise" variant available now.
A common practice is to check at runtime if a "Precise" call is
supported by the OS version under which the application is currently
For example, at program startup try to import the symbol
GetSystemTimePreciseAsFileTime and set up a function pointer with it. If
the symbol can't be imported (e.g. if running on windows XP) set the
pointer to GetSystemTimeAsFileTime, and get system time stamps only by
calls via that pointer. So you have a single executable which benefits
from the "Precise" call if available, and falls back to the standard
call if it's not available.
provides a good overview of the available functions.
More information about the time-nuts