David, See the documention on the true option of the server command. Compare with the prefer and noselect options.
Dave David Woolley wrote: > Danny Mayer wrote: > >> It has changed. RFC 1305 describes NTPv3. You need to see Section 11.2 > > > As far as I can see, the intersection algorithm hasn't changed. > >> of the NTPv4 draft for the current selection algorithms. Particularly: >> >>> If the selection >>> algorithm cannot produce a majority clique, or if it cannot produce > > > Note the "or" in the condition for rejecting everything; that's an "and" > for not rejecting. The CMIN check is done, rather later, and only if > the absolute majority check succeeds. > > As it happens, there is an undocumented option in the code of 4.2.4p4 > which allows one to force a peer to be a truechimer, even though it > fails the intersection algorithm, but an ordinary users isn't going to > find that option. > >>> at least CMIN survivors, the system process exits without >>> disciplining the system clock. If successful, the cluster algorithm >>> selects the statistically best candidate as the system peer and its >>> variables are inherited as the system variables. >> >> >> CMIN is currently 1. Notice that it says nothing about using more than >> one. > > > All that means is that if you only have one clock that passes sanity, it > will be used. If you have two that pass sanity and they are > incompatible, they will have been eliminated before it even gets to the > CMIN test. > > I'll leave it to Dave Mills to volunteer the undocumented option, if he > thinks it is safe to use in this application. > > (The use of orphan mode can also override the intersection algorithm.) _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
