In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Alexander Perlis) wrote:
> Greetings. Can someone tell me what to try next to figure out the > following problem? We're stumped. You haven't really provide any hard information, but a wild guess would be misuse of local clock in an isolated time island. To make a start, we need the contents of the ntp.conf file, and the result of the ntpq peers command. As you seem to be rejecting responses, the output of ntpq's rv command for each server association is also likely to be useful, as it should contain the reject reason. The tcpdump trace might also be helpful. The system call trace isn't really much use. > All our servers have identical ntpd configurations. Sometimes one of This is not a good idea unless they all have *real* hardware reference clocks of the same type, and even then, that is not a good idea unless it is the same hardware clock with its output replicated, at the hardware level (which can be useful for very tight synchronisation, at the expense of availability), otherwise diversity in clock type and manufacturer is desirable. Specifying the same external servers is bad, because it means there is no diversity and also puts an unnecessary load on the servers. Configuring only local clock on all of them will produce all sorts of instabilities; if there are multiple systems with local clocks, with or without a real source of time, there should be a clear hierarchy. If you don't understand this, you should not use local clock at all; it is not as necessary as people seem to think. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
