Kernel slew/PLL (from IRC)

[Hal Murray]

dfranke said:
esr1: userspace code can't be
substitute for the kernel PLL 
regardless of accuracy. The benefit
of kernel PLL is that the clock never
has to move discontinuously, because
the kernel can apply the smoothing
while handling the clock_gettime
system call. If you adjust the clock
from userspace, you can have
arbitrarily small discontinuities but
you're still going to have
discontinuities.

I think two things are getting confused.  One is the ability to slew the 
clock.  The other is a PLL to automate tracking a PPS.

Deep inside the kernel, there is code that updates the time by reading the 
cycle counter, subtracting off the previous cycle count and multiplying by 
the time/cycle.  The actual implementation is complicated mostly to maintain 
accuracy.  You need ballpark of 9 digits of accuracy on the time/cycle and 
that has to get carried through the calculations.

On PCs, Linux measures the time/cycle at boot time by comparing with another 
clock with a known frequency.  If you are building for a specific hardware 
platform, you could compile it in as a constant.
You see things like this in syslog:
  tsc: Refined TSC clocksource calibration: 1993.548 MHz
(grep for MHz)

[Side note.  1993 MHz is probably 2000 MHz rounded down slightly by the clock 
fuzzing to smear the EMI over a broader band to comply with FCC rules.  It 
rounds down to make sure the CPU isn't overclocked.]

There is an API call to adjust the time/cycle.  That adjustment is ntpd's 
drift.  That covers manufacturing errors and temperature changes and such.  
The manufacturing error part is typically under 50 PPM.  I have a few systems 
off by over 100.  The temperature part varies by ballpark of 1 PPM / C.

There is another error source which is errors in the calibration code and/or 
time keeping code.  If your timekeeping code rounds down occasionally, you 
can correct for that by tweaking the time/cycle.

There is another API that says "slew the clock by X seconds".  That is 
implemented by tweaking the time/cycle slightly, waiting until the correct 
adjustment has happened, then restoring the correct time/cycle.  The "slight" 
is 500 PPM.  It takes a long time to make major corrections.

That slewing has nothing (directly) to do with a PLL.  It could be 
implemented in user code with reduced accuracy.

There is a PLL kernel option to track a PPS.  It's not compiled into most 
Linux kernels.  (It doesn't work with tickless.)  There is an API to turn it 
on.  Then ntpd basically sits off to the side and watches.

Most Linux boxes work just fine without that PLL.

--------

I suspect Daniel's comment is valid, but he said "PLL" which doesn't fit.  I 
don't know a good term for being able to slew the clock.

---------

RFC 1589 covers the above timekeeping and slewing and kernel PLL.

RFC 2783 covers the API for reading a time stamp the kernel grabs when a PPS 
happens.


-- 
These are my opinions.  I hate spam.