Kernel slew/PLL (from IRC)
hmurray at megapathdsl.net
Wed Sep 28 09:06:18 UTC 2016
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
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
These are my opinions. I hate spam.
More information about the devel