[ntp:questions] NTP client: Sudden time steps on Linux machines

Heiko Gerstung heiko.removethistext.gerstung at meinberg.de
Thu May 3 08:28:34 UTC 2007


Richard B. Gilbert schrieb:
> Heiko Gerstung wrote:
>> Richard B. Gilbert schrieb:
>>
>>> Heiko Gerstung wrote:
>>>
>>>> Hi Folks,
>>>>
>>>> I have a problem on a NTP client, it seems to face sudden timesteps 
>>>> and I currently do not have any good explanation for this.
>>>>
>>>> (NTP Version is ntpd 4.1.2 at 1.892)
>>>>
>>>> Apr 24 06:56:50 ntpd[13372]: time reset 0.947095 s
>>>> Apr 24 06:56:50 ntpd[13372]: synchronisation lost
>>>> Apr 24 07:23:56 ntpd[13372]: time reset -0.456118 s
>>>> Apr 24 07:23:56 ntpd[13372]: synchronisation lost
>>>> Apr 25 03:56:56 ntpd[13372]: time reset 0.949329 s
>>>> Apr 25 03:56:56 ntpd[13372]: synchronisation lost
>>>> Apr 25 04:23:53 ntpd[13372]: time reset -0.457310 s
>>>> Apr 25 04:23:53 ntpd[13372]: synchronisation lost
>>>> Apr 26 00:57:03 ntpd[13372]: synchronisation lost
>>>> Apr 26 01:15:09 ntpd[13372]: time reset 1.072991 s
>>>> Apr 26 01:15:09 ntpd[13372]: synchronisation lost
>>>> Apr 26 01:38:48 ntpd[13372]: time reset -0.467324 s
>>>> Apr 26 01:38:48 ntpd[13372]: synchronisation lost
>>>>
>>>> This happens on a few machines running in a classified network and I 
>>>> am not sure if it will be possible to update the NTP on these 
>>>> machines. I just wanted to know if one of you ever came across such 
>>>> a behavior or what good (or not so good) reasons could cause this.
>>>>
>>>> The logs do not show specific jobs running at those times. According 
>>>> to my customer the time offset will not be corrected when NTP is not 
>>>> running (or is told not to correct the clock), therefore I am quite 
>>>> sure that this is not caused by NTP itself but by some other process 
>>>> / kernel misbehaviour.
>>>>
>>>> But a 1 second jump every few hours? Wow ...
>>>>
>>>> Regards,
>>>> Heiko
>>>
>>>
>>> It doesn't look quite that simple.  It's jumping +1, -1/2, +1, -1/2. 
>>> Something is very wrong there but it's hard to tell what it might be 
>>> from the evidence presented.
>>
>>
>> Yes, but the -0.5s step is due to ntpd trying to correct the offset. 
>> If you do not use ntpd to correct this stuff, it will simply jump in 
>> one direction and stay there :-( ...
>>
>> Is there anything I could check or anything you would need to see in 
>> order to strike out possible reasons?
>>
>> Regards,
>> Heiko
> 
> Is there another program trying to control the clock?
> 

Crontab does not show anything like ntpdate and the process list does 
not show any other suspects. This is a (very old) Redhat system, I guess 
they used ntpdate all the time and not chrony or something like that?!

Regards,
Heiko




More information about the questions mailing list