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: [email protected]
[mailto:[email protected]] On Behalf Of
David Taylor
Sent: Friday, November 8, 2013 1:59 AM
To: [email protected]
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
[email protected]
http://lists.ntp.org/listinfo/questions
--
Take care. Thanks, Brian Inglis
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
