Roger wrote:
On Sat, 21 Feb 2015 18:44:54 +0000 (UTC), William Unruh
<[email protected]> wrote:

Why should it not continue to poll it? It should be pruned as a bad
ticker by the ntpd algorihm, and thus not affect the clock discipline.
But that offset might be just a temporary abberation and that source
come back on sync in a few hours or days. Why throw it away. And as has
been mentioned, apparently the pool servers are monitored and if a
source is persistantly bad, it will be removed from the pool.
Ie, what is the harm in continuing to poll it?

To prune or not to prune, that is the question.

If the design of the pool command is that ntpd should drop a
server which is obviously wrong then it should drop it and the
question is why didn't that happen in my case.

The design is to always compare all servers against the rest (i.e. median value), dropping the outlier, then repeat until there is a quorum remaining.

Pruning should only happen if there are a too many servers, and only if you can replace them with new DNS results.

Terje

It's possible that my understanding of the pool command is
faulty and that ntpd behaved as designed. If that is so I
should like to be told that I am mistaken.

The design of the pool command is something you'll have to
discuss with others.



--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions

Reply via email to