[ntp:questions] NTP makes a time jump

Rob nomail at example.com
Thu Jul 11 08:13:46 UTC 2013

karpekin at gmail.com <karpekin at gmail.com> wrote:
> Hello,
> Clients indeed followed server after 2.5 hours. 
> This night they managed to come from -15s difference to +2.5s and now it seems trying to slew another direction. They will probably need another half a day to stop oscillations and finally come to zero. Pity I can't attach a trend picture here, looks pretty funny.
> The only doubt I have is the initial 2.5 hours delay. Server rushed away from clients by ~8 seconds. Clients also moved away from each other a bit, but still max was 480 ms. So the system didn't make jumps but it broke apart for almost 12 hours.
> Any advices how to make them all behave and be closer to each other?

This happens because you do tests that the ntp daemon was not designed
to withstand.
We read it all the time on this newsgroup.  People want to install ntp
and they have been asked to make a testplan and do tests.  They think
about some stresstesting and draw a plan.  They pull plugs, set the time
to incorrect value, connect again, restart the daemon, etc.  But that is
not the environment that ntpd expects to be operating in, and in fact
it performs very badly in it.

So you need to decide: do I want to use ntpd and use it only within its
expected operating environment (i.e. at most pull network plugs but do
not disturb the clock in an unrealistic manner), or choose another ntp
implementation that can withstand those tests (and may perform less well
in day-to-day use).

I hear about chrony all the time.  It should be better in correcting
incorrect time quickly.  I never used it.

But I know very well about the effects that you encounter with ntpd.
Even "fiddling" with ntpd, changing the config file a couple of times
and every time restarting the daemon, will heavily confuse it and you
will see it moving AWAY from the correct time for a while.

More information about the questions mailing list