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
