[ntp:questions] Clock skew changes drastically between reboots

Spoon devnull at localhost.com
Mon Apr 2 16:37:45 UTC 2007

Spoon wrote:

> Hans Jørgen Jakobsen wrote:
>> Dmitry Ivanov wrote:
>>> Spoon wrote:
>>>> 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 see the same behaviour on many systems. Looks like common problem.
>> Could it be that some systems at reboot try to calibrate the clock
>> (whatever that might be) relative to the TOD chip?
>> On some systems the TOD chip has the lowest frequency offset
>> and this would on systems not runing NTP lead to a system drifting less.
>> But it's poison for the value in the driftfile.
> # dmesg | grep -i calib
> Calibrating delay using timer specific routine..
>   2535.15 BogoMIPS (lpj=12675781)
> Are you referring to this calibration?
> I'll check the source code to find where this message comes from.

It's coming from init/calibrate.c

/* This routine uses the read_current_timer() routine and gets the
  * loops per jiffy directly, instead of guessing it using delay().
  * Also, this code tries to handle non-maskable asynchronous events
  * (like SMIs)


I see it's possible to skip the calibration code by providing a boot 
time parameter. I'll test this and report back here.


More information about the questions mailing list