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