[ntp:questions] Re: NTP clients not syncing up to servers?

Danny Mayer 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
>>>132.163.4.101:  *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.
> 
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.
> 

Danny



More information about the questions mailing list