[ntp:questions] NTP Peer Keeps Swapping on Start-up
david at ex.djwhome.demon.invalid
Mon Oct 4 22:35:39 UTC 2010
> On Oct 4, 4:40 pm, David Woolley <da... at ex.djwhome.demon.invalid>
>> 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