On 2014-12-03, Brian Utterback <brian.utterb...@oracle.com> wrote: > On 12/2/2014 4:00 AM, Rob wrote: >> The whole "have 3 servers to select a majority" thing is absolutely not >> required when your servers are accurately synchronized themselves and >> your requirements are "only" within-a-second. It is true that when you >> have two servers the clients cannot know which one is right, but it is >> trivial to keep servers within a millisecond of eachother with GPS and >> within 10 milliseconds using only network peering. To that is two >> orders of magnitude better than you require. > > Be careful with this generalization. While it may be "trivial", it isn't > "automatic". I deal with customers all the time that have configured > exactly two servers on their clients and then are surprised later when > all of the clients become unsynchronized and start free drifting. I > always recommend against it. I still think that it takes four to > guarantee a majority but I don't have proof of that. Someday I will > spend some time to either prove or disprove it, but alas, time is > something I don't generally have extra to spend. But you are better off > with one than two from an operational standpoint.
One or three. Three allows two to outvote one rogue time source. One has no idea what the time is except what that one says. Four will often allow 2 to outvote each of two rogue sources, if those two rogues are not going rogue in exactly the same way. (No matter how many GPS time sources you have, they will all go rogue in the same say if the GPS sattelite system goes crazy for example. However if a couple of the receivers develop some harware fault they will probably deliver different times from each other) Five will allow three to outvote two rogue, even if the two collude with each other. etc. So you decide on the level of redundancy you want, and take your choice. > > Brian Utterback _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions