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

Brian Utterback brian.utterback at oracle.com
Wed Jan 5 15:31:15 UTC 2011


On 01/04/11 17:07, Miroslav Lichvar wrote:
> On Tue, Jan 04, 2011 at 04:12:06PM -0500, Brian Utterback wrote:
>> On 01/04/11 13:44, Miroslav Lichvar wrote:
>>> 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. 
> 
> You mean something like this?
> 
>                   |
> <----------->   <---->
>    <--------------->
>                   |
> 
> Wouldn't be all three marked as truechimers? If there was a fourth
> server it could overlap the leftmost interval and they still would be
> all marked as truechimers.

Let's mark them for the sack of discussion:
                   |
 <c---------->   <b--->
    <a-------------->
                   |

I assume the vertical bars represent the actual time. So, remember
that NTP does not know the actual time, it only knows what is reported
by its servers:

 <c---------->   <b--->
    <a-------------->

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. If you add a falseticker
then all bets are off, because we are talking about detecting a single
falseticker and now you would have two. You see, there is a direct
relation between the number of servers you need to detect a given
number of falsetickers. What makes it worse, is that we are assuming
that the falsetickers are independent. What if all your servers are
all using the same faulty upstream server?
> 
>>> 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. 
> 
> That's not what I see here. Two sources can either overlap or not.
> They can be both falseticker or both truechimers (and the one with
> smaller distance will be the system peer).
> 
>> This can lead to clockhopping,
>> where the system time is alternatingly set to each of the servers in
>> turn.
> 
> 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.

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.


-- 
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