Best practice is five. =) I don't remember if it's in FAQ on ntp.org or in David Mills' book. Your local clock is kind of gullible "push-over" which will "vote" for the "party" providing most reasonable data. The algorithm would filter out insane sources which run too far from the rest and then group sane sources into 2 "parties" - your clock will follow the one where runners are closer to each other. That is why uneven number of trustworthy sources at least at start is required. With 2 sources you will blindly follow the one which is closer to your own clock. You're also having the the risk to degrade into this situation when you lose 1 out of 3 sources. Four is again 2:2 and only with five you have a good chance to start disciplining your clock into the right direction at the right pace, so when 1 source is lost you (most probably) won't run into insanity.
On Sun, Feb 9, 2014 at 9:03 AM, Saku Ytti <s...@ytti.fi> wrote: > On (2014-02-08 19:43 -0500), Jay Ashworth wrote: > > > In the architecture I described, though, is it really true that the odds > > of the common types of failure are higher than with only one? > > I think so, lets assume arbitrarily that probability of NTP server not > starting to give incorrect time is 99% over 1 year time. > Then either of two servers not giving incorrect time is 0.99**2 i.e. 98%, > so > two NTP servers would be 1% point more likely to give incorrect time than > one > over 1 year time. > > Obviously the chance of working is more than 99% maybe it's something like > 99.999%? And is that really typical failure-mode or is typical failure-mode > complete loss of connectivity? Two NTP servers would protect from this, > single > not. > However loss-of-connectivity minor impact on clients, wrong time has major > impact of client. > Maybe if loss-of-connectivity is fixed in somewhat short period of time, > single NTP always win, if loss-of-connectivity is fixed typically in very > long > period of time, single NTP loses. > > I don't really have exact data, but best practice is >2. Matthew said 4, > which > gives the advantage that in single failure you are still operating > redundantly > and do not have urgency to fix, with 3 in single failure another failure > must > not occur before it is fixed. > I think 3 is enough, networks are typically designed to handle 1 arbitrary > failure at the same time and 2 arbitrary failures in most networks, when > chosen correctly, will cause SLA breaking faults (Cheaper to pay SLA > compensations than to recover from any 2 failures). > But NTP servers are cheap, so if you want to be robust and recover from n > false tickers, have 3+n. > > > > -- > ++ytti > >