[ntp:questions] Fwd: Re: ntpd sensitivity to ordering of servers in ntp.conf?

Weber wsdl at osengr.org
Thu Feb 25 21:44:26 UTC 2016


You are a wise man, sir! That is exactly what was happening.

I tried adding a new first server entry in ntp.conf -- for a 
non-existent IP on the same subnet. Whatever was going to sleep or 
timing out during the delay between polls got refreshed when ntpd tried 
to contact the first (non-existent) server. Now the delay and offset to 
the two NTP servers agree almost perfectly. I'll need to run this for 
several hours to be sure but it is probably good to a couple of 
microseconds or better.

Based on your suggestion, I have to conclude that the cause is probably 
more closely tied to Linux and/or PC hardware than it is ntpd.

Thanks for the idea!

On Thu, Feb 25, 2016 at 02:49:48AM -0800, Weber wrote:
>  ntp.conf is specifies both servers with minpoll 4/maxpoll 4. Peer and loop
>  statistics are enabled.

>  By just changing the order of servers in ntp.conf the delay and offset
>  values in peerstats are swapped. Now it is A with 60us delay and B has 85us.
>  Similarly, A's offset is not -5us and B is showing +5us.
>  It appears there is something in ntpd where measurements on server A in
>  ntp.conf come out slightly different depending its ordering in ntp.conf.

When A is specified as first in the config, the interval between
polling of A and B will be 1 second and the interval between B and A
will be 15 seconds. When you swap the servers, the intervals will be
swapped too. I think there could be a lot of things than would happen
in 15 seconds, but not in 1 second. Maybe some power saving feature is
activated or maybe some cache entry expires.

You could try adding B manually via ntpq -c config:, timing the
command so that the polling is exactly between two polls of B, and
see what happens with the delays. Or you could run ping against the
servers to keep the link "up".

The direction in which the offset changed suggests it's the processing
of the server packet that has the extra delay.

Miroslav Lichvar

More information about the questions mailing list