In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: > .... And a few minutes later ...
Where a few minutes will be the very approximately 15 minutes needed to verify a step change. If the local clock is the first one to become reachable, it will lock onto that and then require the full broken clock verification delay to change. > 1) Why would ntpd choose to use its higher stratum system clock rather > than a lower stratum server and why would ntpd cycle between them? I'm not sure that it is worth analysing in detail in the light of the following, but in the example you have only two clocks and their error bands don't overlap, which is never a good thing. They also differ by more than 128ms, so if ntpd locks onto one initially, it can take some time to change to the other. > 2) In the non-master node's ntp.conf, should I just remove the listing > of its system clock as a server? Is it completely unnecessary as the > non-master node is only a client? Local clocks should never be configured on leaf nodes. They don't help and they can cause confusion. They are over used on server configurations; they inhibit the propagation of the indication that the time is unreliable. > 3) In general, is the way I'm setting up the ntp.confs for the nodes > on the cluster reasonable? You should either remove the local clock from the server, or give it enough upstream servers to outvote the local clock. (Local is treated in a special way that might partially mitigate this, but I don't want to trawl the code to be sure.) _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
