[time-nuts] Linux timekeeping / jiffy source

Mike S mikes at flatsurface.com
Fri Dec 3 07:38:13 EST 2010

>>On Dec 2, 2010, at 10:17 PM, mikes at flatsurface.com (Mike S) wrote:
>>is it possible to restart the Linux kernel without a full reboot 
>>(avoiding BIOS initialization)
>At 02:17 AM 12/3/2010, Christian Vogel wrote...
>It's called "kexec".

Thanks. I'll try it in a bit.

At 02:22 AM 12/3/2010, Hal Murray wrote...
>The problem is in the TSC calibration routine.  If you patch the 
>source code
>to call it multiple times and print each answer, you will get various


>Somebody "cleaned up" the Linux timekeeping code a year or two 
>ago.  Scan
>your /var/log/messages for something like:
>   Nov  7 08:40:13 shuksan klogd: Detected 2792.933 MHz processor.
>   Nov  7 08:40:14 shuksan klogd: Switching to clocksource tsc

Looks like you've got it!
[    0.000000] Detected 2410.978 MHz processor.
[    0.912030] Switching to clocksource tsc

>There are now several possible clock sources.... Look in 
>/Documentation/kernel-parameters.txt and search for clocksource

You're a fount of good info. Something else to play with:
clocksource=    [X86-64] hpet,tsc

At 02:23 AM 12/3/2010, Kasper Pedersen wrote...
>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.

NTP is running, and testpmt cranks out numbers at several per second. 
They're mostly in the low 32's. The clocksource is tsc, and ntptime is 
adjusting -6 ppm. So, tsc and PMT apparently differ by 38 ppm (or maybe 
26, not sure how the signs work).

>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.

I'm running ARM64 (aka X86-64), acpi_pm appears not to be an option, 
according to 
http://www.kernel.org/doc/Documentation/kernel-parameters.txt Does the 
kernel really calculate based on 14.318180? I find this in dmesg: 
"[0.904194] hpet0: 3 comparators, 32-bit 14.318180 MHz counter" Is that 
because mine is being measured wrong, someone chose the wrong rounding 
(sb 14.318182), or a granularity limitation of HPET? The proper 
frequency is a repeating decimal 14.31818181818... (= 4.5 MHz / 286 * 
455 / 2 * 4). To a time nut, the difference is 127 ppb.

More information about the time-nuts mailing list