On 01/04/11 13:44, Miroslav Lichvar wrote: > Hi, > > I'm wondering about the section 5.3.3 on the ntp support web > > http://support.ntp.org/bin/view/Support/SelectingOffsiteNTPServers#Section_5.3.3. > > It says and explains that minimum number of servers to detect one > falseticker is four, is that really correct? I understand that four is > better for reliability, but from the algorithm description > (http://www.eecis.udel.edu/~mills/ntp/html/select.html) and my tests > with a simulated falseticker it seems that three is enough. >
Three are often sufficient, but not always. The key issues are which is the falseticker and how far apart they are and what the dispersion is. A falseticker by definition is one whose offset plus and minus its dispersion does not overlap the actual time. So, if two servers only overlapped a little bit, right over the actual time, they would both be truechimers by definition, but if a falseticker overlapped one of them bu a large amount, but fell short of the actual time, it could cause NTP to accept the one truechimer and the falseticker and reject the other truechimer. Then left with with those two, the actual time would not be in the overlap interval, and NTP would have no reason to prefer the truechimer over the falseticker, so the falseticker could be chosen as the system peer. > Also, while running with two servers might be the worst configuration > for ntpd, it still could be prefered over the configuration with only > one server by users who would rather have two sources marked as > falsetickers and know a problem needs to be fixed than unknowingly > follow a bad truechimer. The problem is that the two servers would never be marked as falsetickers at all, since NTP could not eliminate either one of them. Both would be accepted as truechimers. This can lead to clockhopping, where the system time is alternatingly set to each of the servers in turn. This causes the system clock to oscillate and can lead to unstable oscillations, with the clock getting further and further off from the actual time, then reversing course and overshooting in the other direction, back and forth. Thus you can end up with your system having an arbitrarily large offset from the actual time, with the time being jumped forward and back. This is pretty much worse than not setting the clock at all. > > Is it possible to reword that section? > > Thanks, > -- blu Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. - Martin Golding -----------------------------------------------------------------------| Brian Utterback - Solaris RPE, Oracle Corporation. Ph:603-262-3916, Em:brian.utterb...@oracle.com _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions