On Aug 3, 5:23 pm, David Woolley <[email protected]> wrote: > E-Mail Sent to this address will be added to the BlackLists wrote: > > > > >> remote refid st t when poll reach delay > >> offset jitter > >> ============================================================================== > >> *LOCAL(0) .LOCL. 10 l 56 64 1 0.000 > >> 0.000 0.000 > >> linux_time_svr LOCAL(0) 3 u 45 64 1 0.578 747067. > >> 0.146 > > > That looks like the client is almost 12.5 minutes off from the server? > > > Try turning panic off? ... or do a NTPdate or NTPd -q first? > > Panic won't help, as it is less than 1000s. The real problem is that > he's got a local clock defined for no good reason (local clocks should > only ever be configured by power users, and generally never on leaf > nodes) and not enough real servers to outvote it (although I thought the > rules did cause a real server to override a local clock). > >
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. _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
