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

David Woolley david at ex.djwhome.demon.invalid
Mon Oct 4 22:35:39 UTC 2010

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.

More information about the questions mailing list