Subject: [Ntp] Is one refid enough

From: Watson Ladd <[email-masked]>
Date: Wed, 4 Sep 2019 21:52:40 -0700

Dear all,

On thinking about some of the discussion that emerged that came from
refids I've come to the conclusion that some of the uses people are
imagining for a complete chain aren't actually going to work, and we
might not even need any refid. Note that my experience in this area is
minimal: this should be more a suggestion of conversation then taken
extremely definitively.

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.

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.

As I mentioned above I'm not that experienced in this part of NTP and
would appreciate any corrections on matters I may have misunderstood.

Sincerely,
Watson Ladd

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 5 Sep 2019 10:41:21 +0200

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

> vs. waiting for C to drift enough for D to switch before synchronizing

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

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 05 Sep 2019 11:06:05 +0200

>>> Miroslav Lichvar <[email-masked]> schrieb am 05.09.2019 um 10:41 in
Nachricht <20190905084121.GL15024@localhost>:
> On Wed, Sep 04, 2019 at 09:52:40PM ‑0700, Watson Ladd wrote:

I think in this scenario there is no possibility for a loop. However if C and
D would peer, C could get time directly from A and also (at a higher stratum)
from D. The point is whether C will still benefit from peering with D (I think
yes, if D is closer (in an NTP sense) to C than A).

> loop. They have to check the refid to prevent that from happening.

Anyway C and D's stratum will go up in some ping-pong manner until they stop
syncing from each other (assuming there's no other refclock available)

> I think it's expected to work.

NTP can be surprising some times: Some time in the past (NTPv3) we had a
handful of servers located in the same machine room. All the servers peered
with each other and had one reference clock, and a LOCL fallback at stratum 12.
I observed that the "peer crowd" drifted away from the reference clock,
eventually declaring it invalid, because the clock quality between the peers
seemed so much better (they all had agreed on some wrong time).

Regards,
Ulrich

> 
> ‑‑ 
> Miroslav Lichvar
> 
> _______________________________________________
> ntp mailing list
> [email-masked] 
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Heiko Gerstung <[email-masked]>
Date: Thu, 5 Sep 2019 12:52:00 +0200

Hi Watson,

> On 05.09.19, 06:54 "ntp im Auftrag von Watson Ladd" <[email-masked]
> im Auftrag von [email-masked]> wrote:
> 
> Dear all,
> 
> On thinking about some of the discussion that emerged that came
> from refids I've come to the conclusion that some of the uses people
> are imagining for a complete chain aren't actually going to work,
> and we might not even need any refid. Note that my experience in this
> area is minimal: this should be more a suggestion of conversation then
> taken extremely definitively.
> 
> 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.

The InstanceID idea would help if a client is configured to use multiple sources and wants to avoid all of them getting their time from GPS (maybe over several stratum levels), if other sources like Galileo or Glonass etc. are available as well. Think about a client resolving 4 pool servers and asking all of them where their time originally comes from. If all of them lead back to the same source (GPS), the client can decide to resolve more pool servers in order to find a set of 4 servers that offers some diversity. Or, it detects that in the original set of resolved IP addresses, two get their time from the same stratum 1 server, allowing the client to discard one of them and find another in the pool that gets its time from a different upstream source.

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

Peering is a thing that I do not see being used very often with our customers. I did not consider peering in my thoughts about the "chain" so far, because I typically see more or less tree-like sync hierarchies. 

> would appreciate any corrections on matters I may have misunderstood.

I would expect that a loop in NTP is typically prevented by the stratum level mechanism, if you never accept an upstream server having the same or a higher stratum level than yours, you should not be able to create a loop anyway. I therefore would accept that the refID itself is not required to prevent sync loops, no matter of which degree.

if A Is stratum 1 and A->B->C->D then B would never choose D because it is stratum 4 and B itself is stratum 2. 

Having a chain of unique InstanceIDs would still be useful because of the first use case. It would also help to find out if two servers A and B are actually the same device with two IP addresses and maybe even network connections. 

> Watson Ladd

Best Regards. 
   Heiko

-- 
Heiko Gerstung 
Managing Director

MEINBERG® Funkuhren GmbH & Co. KG
Lange Wand 9
D-31812 Bad Pyrmont, Germany
Phone:    +49 (0)5281 9309-404
Fax:        +49 (0)5281 9309-9404

Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung

Email:
 [email-masked] 
Web:
 Deutsch   https://www.meinberg.de
 English    https://www.meinbergglobal.com

Do not miss our Time Synchronization Blog:
 https://blog.meinbergglobal.com 

Connect via LinkedIn: 
https://www.linkedin.com/in/heikogerstung

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 5 Sep 2019 13:02:27 +0200

> if A Is stratum 1 and A->B->C->D then B would never choose D because it is stratum 4 and B itself is stratum 2. 

That's how it worked in NTPv3 and it limited the selection
significantly. In NTPv4 clients are allowed to synchronize to sources
having the same or higher stratum. It has some weight in the
source selection (it is included in the root distance), but it doesn't
prevent the selection.

-- 
Miroslav Lichvar

---

From: Heiko Gerstung <[email-masked]>
Date: Thu, 5 Sep 2019 13:07:53 +0200

> On 05.09.19, 13:04 "ntp im Auftrag von Miroslav Lichvar" <[email-masked]
>> if A Is stratum 1 and A->B->C->D then B would never choose D
>> because it is stratum 4 and B itself is stratum 2. 
> 

Thanks for the clarification, in this case the chain of InstanceIDs would also be useful to prevent loops like A-B-C-D-B ..

Best Regards, 
    Heiko

-- 
Heiko Gerstung 
Managing Director

Email:

Connect via LinkedIn:

---

From: Watson Ladd <[email-masked]>
Date: Thu, 5 Sep 2019 08:44:52 -0700

On Thu, Sep 5, 2019, 4:08 AM Heiko Gerstung <[email-masked]>
wrote:

> Thanks for the clarification, in this case the chain of InstanceIDs would
> also be useful to prevent loops like A-B-C-D-B ..
>

If you have no external sources what is the right answer? If you do have
external sources then a loop like this won't form.