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. _______________________________________________ devel mailing list [email protected] http://lists.ntpsec.org/mailman/listinfo/devel
