Richard B. Gilbert wrote: >> > My point was that, in a properly working system, ntpd should not need to > "reset" the clock once it has been synchronized. Let's look at reasons > why this might happen: > a. ntpd selected a new server for synchronization. The selected > server's time differed from the client's by more than the step threshold.
Informational. The new server is neither right nor wrong, just a different one and was different by a large enough amount. > b. the client's clock is drifting at a rate greater the 500 PPM limit > on slew rate. Perhaps a warning if ntpd is not able to keep the clock stable. > c. the client has been unable to get time from a server for a long time, > a lapse in service sufficient to let the client's clock drift past the > step threshold. > Perhaps a warning since it's been unable to get a stable server to use to discipline a clock. > I think that any of the above three reasons would merit a warning or an > error message. Did I miss any possible causes that would rate only an > informational message? > I'm not sure what the error types are currently. Danny _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
