[ntp:questions] Re: NTP clients not syncing up to servers?
mayer at ntp.isc.org
Wed Oct 12 03:58:48 UTC 2005
David Woolley wrote:
> 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
>>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.
True. I was able to get through with ntpd. That machine in Boulder is
running ACTS so it's getting it's chimes through a dialup modem!
> 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
> stratum 2.
The fact that the synch distance is exactly 1.0 is also suspicious.
> Combined with:
> - 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.
These could also be running OpenNTP which also made the same mistake. I
believe they did fix it eventually but we have no idea what these
systems are running.
> 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