Re: [Ntp] Is one refid enough

[Miroslav Lichvar <[e-mail]>]

On Wed, Sep 04, 2019 at 09:52:40PM -0700, Watson Ladd wrote:
> The first use put forward was for redundancy: one would gather
> intermediate sources until enough root sources were gathered. But this
> isn't actually a reflection of the reliability: the NTP environment is
> a graph, and the stratum 1 sources are the roots of a dynamically
> created spanning tree. In particular if we have two stratum 1 sources
> A and B, and two intermediates C and D, then if both C and D are using
> both A and B then there is full redundency, even if both have better
> connectivity and thus use A to synchronize with.

I'm not sure I understand this correctly. Do you mean that C and D
should or should not be synchronized to both A and B at the same time,
even if A is much better than B? I guess that would be up to the
clustering and combining algorithms later in the selection process,
and not anything related to refids.

> The second use was for preventing loop formation: by excluding a
> source that has synchronized to you, this prevents loops. Let's take a
> simple example: A and B are two stratum 1 sources, C and D take from A
> and B respectively, and are peered. Because A is so much more stable C
> synchronizes to it, and D synchronizes to C. Now assume that A goes
> down. What should eventually result is C synchronizing with D and D
> synchronizing to B. The question of which mechanism between using
> reference IDs and accumulating errors/stratum will work better is not
> obvious: it seems to me that not using reference IDs works just fine
> in this example and provides faster recovery: C can synchronize to D
> immediately as it is the best surviving timesource, and the error
> accumulation eventually means D prefers B (in practice quite quickly)
> vs. waiting for C to drift enough for D to switch before synchronizing
> to D.

No, that doesn't sound right to me. If C was significantly better than
B from the point of view of D when A stops working, D might prefer C
over B for quite some time and if C switched to D, there would be a
loop. They have to check the refid to prevent that from happening.

Fast reselection when something goes down is not a goal. As long as C
is better than B, we want C to run free and keep D synchronized to C.
When C accumulates so much dispersion that its worse than B, D will
switch to B and only then C can synchronize to D. At least that's how
I think it's expected to work.

-- 
Miroslav Lichvar