On 12/03/2010 04:17 AM, Mike S wrote: > Anyone familiar with Linux kernel timekeeping? >
On boot, the kernel picks a clocksource. If the cpu is recent, and it is not forced, the tsc (cpu) counter gets chosen. The tsc increment rate is initially unknown, and is measured against pit (8253/8254), and the result may be off if SMI interrupts arrive (these are BIOS interrupts and can not be masked by the OS). The newer the kernel, the more attempts to work around SMI in that part of the code. If this code works, it does not matter what frequency the cpu (and thus tsc) is running, so I suspect this code is failing. Or pit is on drugs. http://n1.taur.dk/permanent/testpmt.c this bit of code will compare the timekeeping clock to the PMTimer, which runs off of plain 14.31818MHz/4. It gives you the frequency offset (in ppm) in a few seconds, and provided ntpd is not started on boot, gives you the scaling error. If you force the kernel to use another clocksource, either clocksource=hpet clocksource=acpi_pm then you may see a rather large error (12 or 127ppm) between PMTimer, and the clock running off of PMTimer. This is due to a rounding error in timekeeping.c, and for that there is this patch: http://n1.taur.dk/timefix2.patch With a good* 14.31818MHz, running the clock off of acpi_pm is now good. With hpet there's another bug, causing a 60e-9 offset. My patch above is not perfect. When it corrects for, say, a 127ppm rounding error, it also inadvertently changes the gain of adjustments. Thus, when you (or ntpd) ask for 1ppm trim, you get 1.000127 ppm trim. Also, my comment about this starting with 2.6.32 is false, it affects much older kernels too. /Kasper Pedersen *as defined by time-nuts. _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.