On Wed, Jan 05, 2011 at 10:31:15AM -0500, Brian Utterback wrote: > Let's equalize a bit to make it a bit more fair: > > <c------------> <b-------------> > <a--------------> > > So, now, if you were NTP, which would you choose? You are correct in > your assessment that NTP would accept them all as truechimers. You are > correct also that adding a fourth still does not guarantee that you > will throw out the falseticker, but NTP uses intervals at this stage, > not actual servers, so adding another truechimer will guarantee that > the interval used will contain the real time.
Not necessarily. | <---------> A | <-----> B <--------> C <-------> D | <==> X Here, B is the only server off, but the result X doesn't contain the actual time. > > I think clockhopping can happen with any number of servers, there just > > needs to be two or more similar sources on top of the list sorted by > > synchronization distance. > > > > With more servers on the list, the clustering and combining algorithms > will merge them into a single offset and they will not hop. With two > servers, these algorithms cannot function. Combining doesn't affect clockhopping, it happens after the system peer is selected. > By the way, over time Dr. Mills has added features to try to suppress > clock hopping as much as possible without compromising the correctness > proofs. With the latest versions, clock hopping may not be so much of > a problem. Bu tit is still an issue. Even if you prefer one clock, it > might be inaccessible for a while and you will hop anyway. Yes, the maximum anti-clockhopping threshold is a fixed value (1 ms by default), so it can't work well in all situations. But it can be tuned with the tos mindist command. -- Miroslav Lichvar _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions