[ntp:questions] Re: NTP clients not syncing up to servers?
david at djwhome.demon.co.uk
Tue Oct 11 22:36:29 UTC 2005
In article <434C2D99.1090602 at ntp.isc.org>, mayer at ntp.isc.org (Danny Mayer) wrote:
> Ted Beatie wrote:
> > It is internal, and looks like it gets it's time from other internal machines;
> > portal-01:~# ntptrace -n
> > 127.0.0.1: stratum 3, offset 0.000006, synch distance 15.20248
> > 10.16.4.1: stratum 2, offset -2.558634, synch distance 1.00000
> > 10.16.4.100: stratum 2, offset -2.571121, synch distance 1.00000
> > 10.16.100.2: stratum 2, offset -2.520537, synch distance 0.04373
> > 184.108.40.206: *Timeout*
> That means that 10.16.100.2 is not actually getting time from anywhere
> and is currently isolated. It can't reach the Boulder timeserver.
No. It means that the machine on which ntptrace is running cannot
get a reply from Boulder.
Strictly speaking one can't be sure that this is the true server chain
as 10.16.4.1 may have got the time from 10.16.4.100 when that was
directly talking to a stratum one server. However I tend to believe it,
in which case at leaast 10.16.4.1 and 10.16.4.100 are BROKEN.
This tend to reconfirm that some of the servers are hardcoded to misreport
- not reporting a fault when the root dispersion is too high;
- using Boulder as a time server.
That very strongly indicates the use of W32Time. W32Time is not an NTP
server. It is not even a valid SNTP server. Before ntpd can be expected
to behave reliably, it must be using conforming NTP servers or hardware
reference clocks. Replace all the W32Time's in the path to the root server
with a valid implementation of NTP.
I think that I should probably add root delay as zero on a non-reference
clock server as another W32Time indicator.
> That means that it's not synchronized and it hasn't even decided on how
> valid or invalid each of them are.
Which is because they all have root dispersions well above Max Distance,
in spite of falsely claiming to be synchronised.
> > How long would it take with iburst set? How can we deal with the fact
> > that the gateways and servers all generally come up at the same time?
It actually showed at least 8 responses; all the filter slots were full.
The one poll diagnosis is a red herring.
> Usually with iburst it can be as fast as 15 seconds but it depends on
> lots of factors. I don't think this is your issue here.
Like have conforming, synchronised, servers upstream.
More information about the questions