[ntp:questions] NTP Peer Keeps Swapping on Start-up

Richard B. Gilbert rgilbert88 at comcast.net
Tue Oct 5 00:11:13 UTC 2010

On 10/4/2010 6:35 PM, David Woolley wrote:
> SteveW wrote:
>> On Oct 4, 4:40 pm, David Woolley <da... at ex.djwhome.demon.invalid>
>> wrote:
>>> SteveW wrote:
>>>> Also, just to clarify regarding the reach value, the snippet I showed
>>>> is right at start-up and it quickly goes to 377 for the remote ntp
>>>> server and remains there.
>>> ntpq assoc, followed by ntpq rv for the association number.
>>> Typically the problem is that the local clock has rather narrow error
>>> bounds, and if the remote source disagrees, but also has narrow error
>>> bounds, there is conflict as to which one has the true time. If you
>>> have a legitimate need for a local clock, you should make sure all your
>>> local clocks can be outvoted by real clocks.
>> How do I make sure the local clocks can be outvoted by real clocks?
> You ensure that more server lines reference servers traceable to true
> time, than reference servers dependent on a local clock.
>> Also, here is the result from debug:
>> [16:53:13] ind assid status conf reach auth condition last_event cnt
>> [16:53:13] ===========================================================
>> [16:53:13] 1 58883 9424 yes yes none candidate reachable 2
>> [16:53:13] 2 58884 963a yes yes none sys.peer sys_peer
> Neither is being rejected, but I guess that the anti-clock hopping logic
> is in effect. If this weren't the local clock, I would say the time was
> being disciplined by a combination of both sources. I'm not sure what
> happens with the local clock. rv 0 will tell you what offset value is
> being used to discipline the clock. If only the local clock is being
> used, it will be zero.

It appears that ONLY TWO servers are configured.  This is just about the 
worst possible configuration!  It is written that a man with two clocks 
can never be certain what time it is!

The suggested minimum is four servers.  Five and seven server 
configurations are a bit more robust.  Ideally, the servers should be 
close to you in net space; the lowest round trip times usually indicate 
the best servers for your use.

More information about the questions mailing list