Subject: [Ntp] NTPv5 modular architecture

From: Doug Arnold <[email-masked]>
Date: Wed, 22 Jul 2020 14:48:25 +0000

Here is a slightly expanded version of the modular architecture concept for NTPv5.  Feedback welcome.

Doug

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 23 Jul 2020 08:13:44 +0200

Hi!

A few random notes on the block diagram:

* the "config" arrows to management should be bidirectional IMHO, unless the management keeps the complete config (so that it is readable)

* shouldn't there be an arrow between protocol engine and timing engine?

* I feel unsure about hw timestamps being derived from the system clock; wouldn't that be software time stamps then?

* Doesn't the timing engine have to read the system clock as well?

* I'm missing to "external" arrows: That to the network for both, management and network stack. So to say: Will there be another network stack for management, or will it be the same?

On protocol engine:

* I'd delete "for transmission", as it's more the task of the network stack, I guess

* "building packets (to send)" and "determines when to send packets" is basically the same for me, assuming a packet is sent as soon as possible after being handed to the network stack

* Does the timing engine really care about messages not received? IMHO it's part of the protocol engine. Likewise security and message status. In my view the timing engine is fed with timing information only, and maybe it has to handle the fact when it does not receive any.

On timing engine:

* Does the timing engine really select the servers? Isn't that the protocol engine (with information from the timing engine)?

* I'd replace "report statistics to management interface" with "provides performance numbers for protocol engine and management interface"

Regards,
Ulrich

>>> Doug Arnold <[email-masked]> schrieb am 22.07.2020 um 16:48 in
Nachricht
<[email-masked]>

---

From: Hal Murray <[email-masked]>
Date: Thu, 23 Jul 2020 01:29:21 -0700

How about separate blocks for client and server?

And another optional block for local non-network sources of time.

-- 
These are my opinions.  I hate spam.

---

From: Doug Arnold <[email-masked]>
Date: Thu, 23 Jul 2020 13:51:04 +0000

Hello Ulrich,

Thanks for the observations and insights.

The presentation definitely needs more work on the management interfaces.  I was envisioning the timing engine and protocol engine reading a configuration file.   However, you are right, that for every SET there should be a GET, so that the management interface can query or verify the configuration.  The arrows should be bidirectional.

Yes, the (bidiretional) arrow between timing engine and protocol engine was inadvertently left off the diagram.

In practice the management interface might have its own stack or share one with the protocol engine, but it should be indicated on the diagram.

On the protocol engine:
Deciding when to send packets is definitely something a PTP client does.  They way I have divided things up the timing engine picks an average packet interval and the packet engine sets timers to make that happen either with constant or randomized intervals depending on what ntpv5 calls for.

Since the client timing engine is picking the servers, it needs to know if the servers are not responding.  It could infer that when no information from those servers are delivered by the protocol engine, but it might be helpful for the protocol  engine to say explicitly that I send a packet and didn't get a response within the response time out interval.

On the timing engine:
Since the timing engine is analyzing the timing data, including things like identifying false tickers, then it should pick the servers

Provides performance numbers is better than report statistics, as it is a little more general and flexible.  As long as the timing engine is the one selecting servers and packet rates, than the protocol engine does not need to know the performance.

Doug

________________________________
From: Ulrich Windl <[email-masked]>
Sent: Thursday, July 23, 2020 2:13 AM
To: [email-masked] <[email-masked]>; Doug Arnold <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Antw: [EXT] [Ntp] NTPv5 modular architecture

Hi!

On

On protocol engine:

On timing engine:

Regards,
Ulrich

Nachricht

---

From: Doug Arnold <[email-masked]>
Date: Thu, 23 Jul 2020 13:54:38 +0000

Hello Hal,

I agree.  Trying to do a client and server on the same diagram would just result in a mess.

Doug

________________________________
From: Hal Murray <[email-masked]>
Sent: Thursday, July 23, 2020 4:29 AM
To: Doug Arnold <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Ntp] Antw: [EXT] NTPv5 modular architecture