[ntp:questions] Problem facing with Ntp client Configuration

Brian Utterback brian.utterback at oracle.com
Fri Mar 28 14:09:25 UTC 2014


On 3/27/2014 8:46 PM, William Unruh wrote:
> Yes. Argument through hyperbole. There is an argument for more than 1 
> sever, but you should recognize what that argument is. Three are more 
> than enough(that guards against one going crazy.) If you really think 
> that there is chance that more than one will go crazy 5 is good, but 
> if there is resonable chance of 2 going crazy, then the probabilities 
> become high that more than 2 will as well, at which point you enter an 
> arena of dimishing returns. You need to fix your sources, not rely on 
> more and more servers. So, one is fine, recognizing that there is no 
> way of noticing if that one goes crazy. Two are no better than one, 
> and have the danger of hopping from one to the other if one goes 
> crazy, so three is a protection against one going crazy. If it is more 
> than that, you have problems that needs a human to fix. It is true 
> that hard disks have almost half of the bits being parity bits, but 
> they also impliment a rather more sophisticated error identification 
> and correction algorithm than does ntpd. And if one of your sources is 
> going crazy, ntpd should send you a message to that effect so you can 
> fix it, or use a different server.

One is fine if all you care about is that the human readable clock has 
the right time so you are not late to your meetings.

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. 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.

With three you guarantee that there will always be an acceptable 
interval from any three truechimers. But you are susceptible to a 
falseticker here, and remember a falseticker just means that the offset 
interval doesn't overlap with the correct time. As I pointed out above, 
a server only has to be a little off to be a falseticker, but if you 
can't detect it, then your potential for error in your offset grows in 
relation to how far off the falseticker is. Sure, you are better off 
fixing your sources, but it doesn't take much perturbation to throw a 
server off, at least for a while.

I always say if you are serious about time synchronization, then you 
need at least four server, for the reasons given above. You are not 
taking advantage of all of NTP algorithms until you have four servers. 
So, I agree with you that adding more after four is an exercise in 
diminishing returns. Going from four to five might be worthwhile, but 
beyond that doesn't generally add much in my experience.

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.   The fewer 
servers you think are needed to get adequate time sync means the fewer 
data points out of the eight you think are optimal. If one server is 
really enough, then one out of eight is enough. If four servers are 
enough, then four out of eight samples are enough.

Brian Utterback



More information about the questions mailing list