[ntp:questions] Number of servers needed to detect one falseticker?

Brian Utterback brian.utterback at oracle.com
Tue Jan 4 21:12:06 UTC 2011


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.utterback at oracle.com



More information about the questions mailing list