Going to wait until some next patch Tuesday has something for me, then the
restart will pick up NTP config changes which should force PCC/rdtsc use, and I
can see if that is enabled and makes a difference. My system should be able to
maintain constant PCC frequency across SMIs/NMIs and possibly even cpus,
although doing my own process affinity wiring to ntpd eliminates that possible
variable.
On 2013-11-07 23:58, David Taylor wrote:
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
