[ntp:questions] WinNT Port Performance Counter Stability and Drift
elliott.ch at verizon.net
Fri Nov 8 13:40:39 UTC 2013
The result of reading the timestamp counter can vary wildly due to EIST
(speed step technology), turbo modes, and owner overclocking, in addition to
differences in CPUs, as noted. There is quite a bit about this on the
Internet. As I recall, most writers recommend not using it, but if one
must, using it only for short interval timing and after repeatedly measuring
the frequency of the counter. The latter can take quite a bit of time, as
it should be done several times, and for different interval lengths, and
taking the average or median of the results.
Most authors recommend using QueryPerformanceCounter and
QueryPerformanceFreq if it can be determined that these functions are tied
to the High Performance Event Timer (HPET), which they are on most modern
systems. I believe that code to do this is already in NTPD. You can tell
this from the messages in the Event Log (on Windows) when NTPD starts up.
NTPD chooses the timer whose frequency is that of the HPET.
From: questions-bounces+elliott.ch=verizon.net at lists.ntp.org
[mailto:questions-bounces+elliott.ch=verizon.net at lists.ntp.org] On Behalf Of
Sent: Friday, November 8, 2013 1:59 AM
To: questions at lists.ntp.org
Subject: Re: [ntp:questions] WinNT Port Performance Counter Stability and
On 07/11/2013 22:15, Brian Inglis wrote:
> From the attached extract from my ntp log the current performance
> counter appears to have much higher drift ~25PPM than my hardware clock;
> my own calibration, timings, and loopstats over the last couple of years
> show ~0.9PPM.
> A possible reason is that currently when calibrating and using PCC only
> a bare rdtsc instruction is used.
> From discussions in various places, summarized well in the article
> linked below, rdtsc may be executed out of order, adding jitter.
> These discussions recommend rdtsc be preceded by mfence (as it works on
> all PCs that support rdtsc) to avoid out of order execution during
> calibration loops.
> The calibration also needs to be wired to a single cpu, results from the
> first call to the calibration function discarded to eliminate cache and
> pipeline fill delays, and all results significantly higher than average
> discarded because the hardware can switch into System Management Mode
> BIOS at random, mainly to handle USB devices like mice, keyboards, drives.
> links from that, and similar articles on the LKML and MSDN.
Sounds like one for the NTP Bugzilla
questions mailing list
questions at lists.ntp.org
More information about the questions