Re: [Ntp] Modular NTP

[Doug Arnold <[e-mail]>]

Good question. I was thinking that any decision from received data intended to increase time accuracy at the client, would be part of clock contol, and the protocol engine just handles the mechanics of sending and receiving messages.  So source selection and filtering would be part of clock control.

However, it would also be possible to make another subsystem in between clock control and the protocol engine, which would be focused on source selection.  What do you think?

Doug

________________________________
From: Miroslav Lichvar <[e-mail]>
Sent: Monday, April 27, 2020 12:53 AM
To: Daniel Franke <[e-mail]>
Cc: Doug Arnold <[e-mail]>; NTP WG <[e-mail]>; Tal Mizrahi <[e-mail]>
Subject: Re: [Ntp] Modular NTP

On Sat, Apr 25, 2020 at 09:34:09AM -0400, Daniel Franke wrote:
> This interface is very straightforward and I think its description belongs
> in the algorithm document. On the client side, the protocol engine feeds
> the clock control algorithm a stream of decrypted responses annotated with
> their origin and destination timestamps. On the server side, the clock
> control algorithm feeds the protocol engine the clock values that it should
> be responding with.

I presume an RFC 5905 implementation should be easily split in this
scheme. Where is the clock filter and source selection? Are they all
in the "clock control"? The clock filter needs to be compatible with
the control loop. Source selection is between them.

--
Miroslav Lichvar