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

[Miroslav Lichvar <[e-mail]>]

On Tue, Jan 05, 2021 at 03:10:55PM +0100, Magnus Danielson wrote:
> On 2021-01-05 09:33, Miroslav Lichvar wrote:
> > 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.

The kernel and driver have no idea in what timescale the hardware
clock is keeping time, if any. That's up to the applications. Unlike
with the system clock, there is no support for inserting/deleting leap
seconds, so it needs to use a non-leaping representation.

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

Yes, that's the problem I'm trying to point out. The TAI-UTC offset is
not universally available, but it is required for conversion between a
leaping and non-leaping representation of time. It doesn't matter if
it is in the kernel, libc, or the NTP implementation. When I want to
synchronize two UTC clocks, which is probably the most common case,
there is no point in converting the timestamps to a non-leaping
representation and back. If it cannot be done reliably, as is the case
with current systems, it will just make the synchronization less
reliable.

-- 
Miroslav Lichvar