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
