On 10/4/2010 6:35 PM, David Woolley wrote:
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.
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.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
