[ntp:questions] WinNT Port Performance Counter Stability and Drift

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Fri Nov 8 20:44:37 UTC 2013

I set my BIOS and W7 PM settings off a long time ago: stepping, spread spectrum, and all power tweaks are disabled, and PM is high perf no sleep, except monitor and possibly disk (given NTP stats every 16s) after longish timeouts.

I checked the stable and dev code and it uses PCC/rdtsc if that underlies QPC, otherwise QPC, which may be based on HPET if available.
Various articles also discuss HPET variations and errata causing loss of either or both HP and ET requiring patches!

The issue is that QPC drift is ridiculously high and variable, given my base system frequency stability and user mode PPS refclock (serialpps does not stack on top of PCI serial driver).

I can also see issues with no mfence before rdtsc during calibration (could also use lfence on Intel only, but mfence works on AMD as well, or rdtscp if supported in the cpu features bits, which is available on my system, but not older systems).
Also not throwing the first estimate away to eliminate cache and pipeline fill delays, and not discarding outliers from either QPC or PCC caused by SMIs and other NMIs.

On 2013-11-08 06:40, Charles Elliott wrote:
> 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.
> Charles Elliott
> -----Original Message-----
> 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
> David Taylor
> Sent: Friday, November 8, 2013 1:59 AM
> To: questions at lists.ntp.org
> Subject: Re: [ntp:questions] WinNT Port Performance Counter Stability and
> Drift
> 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.
>> See
>> http://lists.freebsd.org/pipermail/freebsd-amd64/2012-July/014756.html,
>> links from that, and similar articles on the LKML and MSDN.
> Sounds like one for the NTP Bugzilla
>     http://bugs.ntp.org/index.cgi

Take care. Thanks, Brian Inglis
questions mailing list
questions at lists.ntp.org

Take care. Thanks, Brian Inglis

More information about the questions mailing list