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 [EMAIL PROTECTED]) > > 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. _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
