Stephen Vaughan wrote:
Connectivity is fine to the ntp servers, if I restart ntpd it starts syncing
with an external clock immediately. This article could be the fix:
http://www.novell.com/coolsolutions/feature/15345.html
This advises some very anti-social practice, namely using burst on
public servers. This is likely to get you banned from those servers.
Also, it doesn't explain why you have zero reachability.
Getting the detailed diagnostics, by using rv on the association
numbers, may give a better clue.
I do have some concern that a local clock could result in all the others
being false tickers, because the error band on the local clock is too
small, but ntpd is supposed to discriminate against the local clock. In
any case, false tickers still have a non-zero reachability.
Actually, one possibility, is that the error statistics on the remote
servers are wrong, resulting in their confidence intervals not
overlapping. That doesn't really work for the Novell example, as they
only have one server. Unfortunately, they've used ntpdc peers, rather
than nptq peers, so one can't really tell how the servers are being treated.
However, in all cases, the basic problem is using a local clock driver
for no valid reason.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
