[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)
  */

http://lxr.linux.no/source/init/calibrate.c

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

Regards.




More information about the questions mailing list