hmurray at megapathdsl.net
Fri Oct 7 02:35:59 UTC 2016
esr at thyrsus.com said:
> What is adjtimex/ntp_adjtime doing that is "drift correction" but not clock
> slewing? I thought clock slewing was wjat that call did.
Deep inside the kernel, the time keeping code does roughly:
time += delta_cycles * time_per_cycle
That works if the cycles are old scheduler interrupts every few ms or a
cycle_counter register running at the CPU clock frequency.
Linux on a PC measures the CPU clock at boot time by comparing it against
some clock that ticks at a known frequency leftover from the early PC specs.
You will find things like this in your syslog/dmesg:
tsc: Detected 1993.669 MHz processor
That number turns into the time_per_cycle
The arithmetic has to be done carefully in order to preserve the low order
bits. You want a lot of them. It's easy to measure the crystal frequency to
To slew the clock, the time_per_cycle is tweaked slightly for a while then
restored where "a while" is the amount of time it takes to slew as far as you
want to go.
If the time_per_cycle is off slightly, the clock will drift. With
ntp_adjtime, you can tweak the time_per_cycle slightly. That's the ntpd
"drift" as stored in the drift file and logged in loopstats.
With the old adjtime (no x), there is no way to adjust the drift.
The idea of drift correction is important. It makes a huge difference if you
get everything else working right.
Typical numbers are 10-50 ppm (parts per million). Such a clock will be off
by 10-50 microseconds per second or 10-50 milliseconds after 1000 seconds.
(The default ntpd setup ramps the polling up to 1024 seconds so it's
reasonable to think about that time scale.)
If your system is running well, ntpd's drift is a reasonable thermometer.
Scan your systems and see what their drift looks like. It's far from rare to
be over 100 ppm. (Some of the problem may be the initial calibration
software rather than hardware. You can use drift to correct for either.)
These are my opinions. I hate spam.
More information about the devel