>I've noticed something I find very strange on the systems I have to work
>with. Every time I reboot the computer, the clock skew of the local
>clock changes, sometimes by what seems to be a huge amount.
>
>For example, I boot the computer, let ntpd run for 12 hours, and the
>value recorded in the drift file is 35 ppm. I reboot the computer, let
>ntpd run for 12 hours, and I get 5 ppm...
I'm chasing the same glitch.
I've seen it on two systems, both i386 running Linux 2.6 kernel.
I think I've tracked it to tsc_init which calls calculate_cpu_khz
both are in ./arch/i386/kernel/tsc.c
tsc_init prints a line like this:
kernel: Detected 2793.226 MHz processor.
The problem is that calculate_cpu_khz doesn't return the
same answer. I hacked the code to call/print it 10 times
and I get things like this:
kernel: Detected 2793.287 MHz processor.
kernel: Detected 2793.225 MHz processor.
kernel: Detected 2793.228 MHz processor.
kernel: Detected 2793.304 MHz processor.
kernel: Detected 2793.242 MHz processor.
kernel: Detected 2793.192 MHz processor.
kernel: Detected 2793.334 MHz processor.
kernel: Detected 2793.203 MHz processor.
kernel: Detected 2793.292 MHz processor.
kernel: Detected 2793.237 MHz processor.
That's a spread of about 50 ppm which matches what I've seen
before I started looking for this glitch.
So I picked a middle (by eye, it's not critical) and added
code like this:
if (1) {
cpu_khz = 2793256;
tsc_khz = cpu_khz;
printk("Smashed to %lu.%03lu MHz processor.\n",
(unsigned long)cpu_khz / 1000,
(unsigned long)cpu_khz % 1000);
}
I haven't rebooted that system enough to see how well it works.
I'm assuming we can fix calculate_cpu_khz. This is just
an ugly hack to see if things will work if we can find the fix.
--
These are my opinions, not necessarily my employer's. I hate spam.
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
