KERNEL_PLL

[Hal Murray]

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 
1E10

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.