[ntp:questions] Problem facing with Ntp client Configuration

Miroslav Lichvar mlichvar at redhat.com
Tue Apr 1 16:34:17 UTC 2014


On Fri, Mar 28, 2014 at 10:09:25AM -0400, Brian Utterback wrote:
> Two is never fine, and not just because of clock hopping. Like the
> old adage, a man with a watch knows what time it is, a man with two
> watches is never sure, NTP will often refuse to set the time with
> just two upstream sources if the two sources do not agree and the
> dispersion intervals do not overlap.

I think we had this discussion before. I wouln't say that two is never
fine. I think two is much better than one if you need to be able to
tell when there is a problem and don't need to recover automatically.
Clock hopping shouldn't be a problem since source combining was
implemented.

> That means that two servers can
> agree on the time to within a millisecond of each other, but is the
> dispersion is less than a half of a millisecond, NTP will not set
> the clock by either of them.

Well, at least one of the servers is a falseticker if their intervals
don't overlap and it should be fixed to not lie about its dispersion.
Adding a third source just to hide this problem doesn't seem right.

> But I would like to point out something to you. You often remind us
> that NTP only uses one in eight data points. But each server you add
> means one more data point used, which means that if eight servers
> were used then NTP would be using the same number of data points
> that it would be if it only had one server and used all the data
> points. 

Please note that the data points are not equal. The point which is
used to update the clock has the shortest distance and may carry more
useful information than the other points combined if the clock is
stable enough.

-- 
Miroslav Lichvar


More information about the questions mailing list