[ntp:questions] What exactly does "Maximum Distance Exceded" mean?

David Woolley david at ex.djwhome.demon.co.uk.invalid
Sat Mar 14 10:35:00 UTC 2009

Joseph Gwinn wrote:
> In article <49bae109$0$505$5a6aecb4 at news.aaisp.net.uk>,
>  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.

More information about the questions mailing list