Joseph Gwinn wrote: > In article <[email protected]>, > Da >> ntpd doesn't care about what the drift is in determining root distance. >> It simply takes the position that the actual local clock will be >> somewhere within +/- 15ppm of the value which would achieve perfect >> phase lock with true time. > > This part seems to conflict with the max +/- 500 ppm steering authority > of NTP. How are these two limits related?
They are not. The 500ppm is the range of correction that can be applied. The 15ppm is a pessimistic estimate of the error in setting that correction. I.E. if there is a valid time source, ntpd may decide it needs a correction of 300ppm. In the absence of that time source, it assumes that the correction it really needed was between 285ppm and 315ppm, with the uncertainty being due to measurement error and changes in the local clock frequency. That uncertainty in frequency causes and uncertainty in time which grows with time, until it, when combined with other uncertainties, exceeds 1 second. The client compares the uncertainty for each server with one second, and when that is exceeded starts ignoring the server. > > >> The assumed maximum reasonable error therefore grows at 15 microseconds >> per second. > > One suspicion I have is that the drifts file has data from some other > test still in it. We will try deleting the drifts file. Root distance exceeded is a problem with the server, not the client. > > Another suspicion is that the computer's sense of time is too far away > from that provided by the timeserver. I would have thought this would > cause the daemon to balk and complain, but perhaps there is a window > where it will not balk but will struggle mightily. We will use ntpdate > as part of the startup process and see if it matters. This will cause ntpd to terminate. I repeat, it is your servers that are being rejected. Generally, in this sort of case, it is helpful to have output from ntpq's peers, assoc and rv commands, with the latter for each association number from assoc and for 0, i.e. the machine itself. That should tell us exactly when the servers had valid time, etc. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
