[ntp:questions] What exactly does "Maximum Distance Exceded" mean?
joegwinn at comcast.net
Sat Mar 14 15:19:47 UTC 2009
In article <49bb8860$0$507$5a6aecb4 at news.aaisp.net.uk>,
David Woolley <david at ex.djwhome.demon.co.uk.invalid> wrote:
> 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.
I understand this, but what perplexes me is that both timeservers, of
different make and model, are showing the same behavior, so I have to
believe that the client is somehow not right. My theory is that we have
not succeeded in getting a clean and correct startup.
By the way, the datasets span at least 24 hours, no startup transient is
seen, and the behavior does not appear to change over the run. So there
may also be a configuration error, but it's hard to imagine what could
> >> 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.
Usually, but the fact that both servers are rejected makes me wonder, as
> > 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.
Yes. The question is why.
For the record:
In this test setup, at any given time, each client (daemon) sees at most
All GPS receivers are fed from a single roof antenna by a splitter.
The mapping between client and server changes only between test runs.
Each run lasts at least 24 hours, and may run over a weekend.
> 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.
Yes. I'll collect this data on Monday.
I have been suspicious of the old Symmetricom ET6010 GPS receiver in the
lab before. Elsewhere in the large system we have observed that
sometimes one must reset the ET6010 to get good time fed to the TS2100
timeserver; no idea why. But the fact that the brand new Spectracom
9383 timeserver cum GPS receiver does the same thing caused focus to
shift elsewhere. By the way, all GPS receivers discussed have Rubidium
More information about the questions