SteveW wrote:
On Oct 4, 4:40 pm, David Woolley <[email protected]>
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.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
