Brian,
The design is to select only one sample in the filter. A read of the
code and inspection of the debug trace confirms that it does exactly
that and results in the behavior I described. Also, from my previous
message to Miroslav, he may be using an older release version which had
a most dubious pedigree. Only recently has the release version became
closely aligned with the development version.
Dave
blu wrote:
On Jun 9, 7:41 pm, "David L. Mills" <[email protected]> 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
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
