[ntp:questions] Problem facing with Ntp client Configuration

mike cook michael.cook at sfr.fr
Fri Mar 28 18:02:22 UTC 2014


Le 28 mars 2014 à 15:09, Brian Utterback a écrit :

> 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.
> 
   However it is not as often emphasized that having independent paths to NTP servers is just as or more important than the number of servers. A common example would be configuring pool servers behind a single access point. If your router or ISP goes on the blink you are a man with no clock. That looks to be too obvious to be worth mentioning, but in another life I saw more ap server time issues due to path failures than due to NTP server failures. 

> 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
> 
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions


More information about the questions mailing list