[ntp:questions] Clock skew changes drastically between reboots

Spoon devnull at localhost.com
Tue Apr 3 16:17:12 UTC 2007


Spoon wrote:

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

Skipping the calibration did not fix the problem.

However, it seems to have an impact.

Sigh... I've run out of ideas.




More information about the questions mailing list