David Woolley wrote:
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (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
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
