[time-nuts] Linux timekeeping / jiffy source

[Kasper Pedersen]

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.