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

[Martin Burnicki <[e-mail]>]

Magnus Danielson wrote:
> Miroslav,
> 
> On 2021-01-05 15:42, Miroslav Lichvar wrote:
>> 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.
> 
> Actually, here lies a problem. There seems to be fairly wide agreement
> that we want the core time-stamping to use a TAI-like form of time. This
> means, it keeps ticking, behaves like a well-functioned linear ramp.
> That makes any processing of it easy and so does all encoding.
> 
> UTC fails to be such a ramp in many encodings. When the leapsecond is
> inserted in 23:59:60, that becomes an encoding challenge for all the
> formats I know.
>  
> TAI achieves this ramp property, and so does TAI-like things like PTP
> and GPS.
> 
> UNIX/POSIX time_t fail this ramp property, as they recode the 23:59:60
> into 00:00:00, which is followed by another 00:00:00.

Yes, that's a problem in the operating system, or more accurately in the
definition of the POSIX time.

> NTPv4 fail this ramp property, as it recode the 23:59:60 into 00:00:00
> and a leap-indication, which is followed by another 00:00:00.

Hm, AFAIK daemons just grab the system timestamp, and they don't even
see a 23:59:60, maybe except in a refclock driver. *If* the daemons sees
it at all, it is already much too late to send a leap second warning to
a client.

And the same problem exists with a PTP daemon if "just sees 23:59:60".

Thus, a proper configuration is required to provide the daemon with
information of an upcoming leap second from a reliable source. And if
you use TAI, you need *in addition* a proper source for the UTC/TAI offset.

> Linux time_T fail this ramp property, as it recode the 23:59:60 into a
> second 23:59:59.
> 
> So, when forces say they really, really want to get rid of these
> encoding issues in the core transport of time-stamps, it's a real thing.
> It will be completely incompatible with UTC transport without means to
> handle things.

As I mentioned before, IMO the default timestamps in the protocol should
represent UTC, for compatibility reasons and because it's probably the
most common use case.

IMO, a possible solution in the role of a server that sends time to its
clients could be

1.) If the operating system doesn't support TAI, things can be the same
as they are now. Just grab the "system time" (CLOCK_REALTIME on POSIX,
GetSystemTimePreciseAsFileTime() on Windows, or whatever) and send it to
clients.

2.) If the OS does support TAI, the server daemon *should* have been
configured in a way that a reliable source for leap second announcements
plus the TAI offset is available, so when the daemon disciplines the
system time, it can write the TAI offset plus a possible leap second
warning to the kernel, so the kernel really has a proper TAI time, and
it knows the TAI offset, and the TAI time at which the UTC offset will
jump due to a leap second.

If a client request is to be handled, the daemon can read the TAI clock
to grab a transmit timestamp, compare the timestamp to the TAI time of
the leap second, determine if the current TAI time is before or after
the TAI time for the leap second, and knows if the old or new TAI offset
is appropriate to compute UTC.

It can then apply the determined UTC/TAI offset to the transmit
timestamp, so simple clients get "UTC" as usual. In addition, the
associated UTC/TAI offset can be put into an extension field. This
allows "enhanced" clients to easily and consistently convert it back, if
they want or need it.

So this approach could be a compatible but enhanced solution for old and
new clients.

If you need to support other time scales for special (telco?)
applications, it should be easy to provide more extension fields that
provide the necessary information for the conversion.


Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: [e-mail]
Phone: [phone]
Linkedin: https://www.linkedin.com/in/martinburnicki/

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy