[time-nuts] Linux timekeeping / jiffy source
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
>to call it multiple times and print each answer, you will get various
>Somebody "cleaned up" the Linux timekeeping code a year or two
>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,
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