[ntp:questions] How should an NTP server fail?

blu brian.utterback at gmail.com
Thu Jun 10 12:29:23 UTC 2010


On Jun 9, 7:41 pm, "David L. Mills" <mi... at udel.edu> wrote:
> Brian,
>
> The number of samples in the clock filter has nothing to do with the
> selection process, nor whether the peer is the system peer or not. The
> selection alogorithm doesn't even know how many samples are in the
> filter, only that the filter candidate that is used has least delay. The
> selection metric includes that and the dispersion at the measurement
> time, plus the dispersion increment since then. When two or more servers
> are configured at substantially the same delay, the client may
> occasionally hop from one to the other depending on these factors,
> although there is a anti-hop scheme that discourages this unless there
> is a substantial difference.

Isn't that the point I was trying to make. You know the old saying, in
theory, there is no difference between theory and practice. In
practice, there is.

My point is that we have the design, the implementation and the
reality. You say it works one way by design and then examine the code
to confirm it. But the user reports something very different. Either
the user is mistaken in the report, is using different code, or there
is a bug. In all three of these scenarios I would think that that the
bug report in bugzilla would have been the appropriate place to
discuss it.

You say above that the number of samples cannot make a difference. The
user says that it does. We need to reconcile these two things.

Brian Utterback




More information about the questions mailing list