Re: [Ntp] CLOCK_TAI (was NTPv5: big picture)

[Magnus Danielson <[e-mail]>]

On 2021-01-05 09:33, Miroslav Lichvar wrote:
> On Mon, Jan 04, 2021 at 06:48:16PM +0100, Magnus Danielson wrote:
>>> The Linux system TAI clock can be read by applications, but there is
>>> no support for timestamping of packets with this clock, i.e. it is
>>> currently not useful for NTP.
>> The hardware time-stamping support will support PTP-timescale, which has
>> a know relationship to TAI. With whatever relationship there will be
>> between NTPv5 transport time-scale and TAI, the PTP relationship will
>> also be known and thus can be used.
> With hardware timestamping there is a separate (hardware) clock used
> for timestamping. It's not related to the CLOCK_TAI system clock
> discussed here.
So, you are saying that the kernel sense of TAI is not used to control
the time of the hardware clock? Fine, but some driver is doing that,
because the hardware clock of a typical is very stupid and is controlled
even with simpler forms than that for which the kernel clock is steered
by NTPD over the nanokernel interface.
>  I assume we don't want NTPv5 to require a hardware
> clock.
While we do not want to require it, we also do not want to exclude it
either. When it is there, the implementation should be able to use it.
> NTP is used for synchronization of various clocks. Most of them are
> based on UTC. NTPv5 cannot support only TAI.

I agree that NTPv5 cannot support only TAI.

However, there comes the first challenge, do the core time-stamp format
be that of a single format or of any timescale format. I think we agree
that formats having the POSIX, Linux and NTPv4 type of leap-second jumps
is to be avoided. OK, so we want something more continuous and then
concluding some variant of TAI-like property, similar to that of PTP is
useful, not at all saying or suggesting it needs to be the PTP one.

Second challenge, if we have a TAI-like core format, and we indeed can
rebuild a TAI replica, and we do not consider this enough, would a TAI
format allows us to fairly cheaply adapt that to other formats? Turns
out that this comes very cheap and is easy to do robust, if and only if,
one has access to the TAI-UTC difference and information about an
upcoming one as that eventually approaches.

Will that satisfy all needs? Maybe not. OK, but will this provide a
vehicle for more variants. Seems likely if we have a standard way of
augmenting the core timing with additional parameters and users add the
mapping.

Sure, I am advocating for a particular part of the solution space. But I
think it is doable without any of the parts becoming cumbersomely
complex to test and verify. An example is how PTP has extension fields
extended by SMPTE 2059-2 and the various output mappings documented
separately in SMPTE 2059-1 to show how the transported parameters
generate all the legacy timing things. SMPTE 2110-10 then extends SMPTE
2059-2 and 2059-1 for the application within the SMPTE 2110 transport
protocols and timing model of media used there. Anyway, I think it is a
fair model that seems to work.

Cheers,
Magnus