[ntp:questions] NTP makes a time jump

unruh unruh at invalid.ca
Thu Jul 11 15:54:32 UTC 2013

On 2013-07-11, Rob <nomail at example.com> wrote:
> 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.

That may be, but he set out his requirements originally. He has a group
of machines that he requires to be within 50ms of each other at all
times. These machines can be disconnected from any outside time source
for weeks at a time, and then come back into connection. If the server
then jumps the time ( it being more than 128ms out) it is clear that all
the machines are NOT within 50ms of each other. The clients will be
minutes out until they notice that they are way out from the server.
Thus, he wants the server to slew not jump. But when he tries to slew he
gets the problem that he mentions here. Thus he is not "testing" ntpd,
he is trying to see if he can get it to do what he needs. 

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

As mentioned that is not what he is doing. 

> 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