Re: [Ntp] Antw: [EXT] NTPv5 modular architecture

[Doug Arnold <[e-mail]>]

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 <[e-mail]>
Sent: Thursday, July 23, 2020 2:13 AM
To: [e-mail] <[e-mail]>; Doug Arnold <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Antw: [EXT] [Ntp] NTPv5 modular architecture

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


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 <[e-mail]> schrieb am 22.07.2020 um 16:48 in
Nachricht
<[e-mail]>

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