Cindy Huyser wrote:
Well, one of the things I'm concerned about here is why 4.2.4p8 will allow IPv4 synchronization and 4.2.6p1 and p2 will not, with relative time differences between server and client roughly the same, and the same configuration file being used. I don't know how it's related (or if it is), but I'm now starting to see ntpq hang when I query peers after starting the ntp time service with 4.2.6p1 or p2, though it works just fine when I revert to the 4.2.4 binaries. This even occurs if the times of the client and the server are within a minute of each other when I start the XP ntp service.
I think there is something wrong there, because ntpd is supposed to use the local clock as a server of last resort, even in rejecting false tickers. However if the real clock is being treated as a false ticker, it would only have to be out by the size of the error band on the local clock, which will be quite small.
This may actually be anti-clock hopping logic, although I think I would expect to see a + in that case.
Basically, though, most people should not have the local clock configured, and I think this includes you, and those who do, should have it outvoted. All the external clock should either be properly locked to UTC or should have root dispersions that reflect their true error tolerance about UTC.
Incidentally, your examples show reachabilities that indicate that the system hasn't been running long enough, or has recently recovered with a time step. Possibly it is hopping between the two sources.
_______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
