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

[Magnus Danielson <[e-mail]>]

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.

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.

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.

Now, if the source side is unable to derive the TAI-UTC difference from
it's timing source (say a simple GPS-receiver), when to resolve this,
some other means of resolvement needs to be done at the server. You
could use a leap-second.list file. You could use DNS based methods. You
could listen to other trusted NTP servers only to attain the TAI-UTC
difference and then re-distribute that. Regardless of which, when
achieved you can provide the full service for all clients.

Then, what happens if neither of these methods become at hand. Shall we
have a way to indicate this. This we should for sure discuss. So, if you
now know you have a good UTC-source, but it is unaided with the TAI-UTC
difference. Can I use it? Sure, it will provide the right frequency and
phase, it's annotation of time can jump strangely on leap-seconds, but
most of the time we will be able to handle it. OK, so a form of reduced
service, but still a service. Here comes the thing to discuss, do we
want to put the burden to handle this on the clients or push it to the
servers?

I think we need to agree on either really just have one time-scale in
the core which will be the same for all NTPv5 users, and with that say
that either you are able to deliver that, or you do not provide the
service. Thus, you require a basic set of adaptation mappings as you go
into the network and then with that you can pick and choose from a set
of adaptation mappings as you go out.

If we say that we indeed can have different time-scales, then each user
then needs to be able to handle the situation of conflicting time-scales
from different servers, either separate or at the same time. I end
thinking madness lies within. One of the things that NTP traditionally
allows us to do is to use multiple servers and weigh them together to a
new composite clock based on their performance (to the client). This is
really derived out of David Allan's clock algorithm work originally.
That will be more difficult to implement if we have diverse time-scales
to source from, notice now that I'm not saying impossible, but more
difficult. We may have to alter those details in the algorithm to handle
the various ways clocks can behave. We would need to know how a
leap-second smoothing clock is doing it's smoothing for instance.

It is exactly these things which makes it such a great idea to have a
very linear ramp type of clock in the core timing, it is a very
attractive technical solution. It will require the handling of TAI-UTC
difference as we get the clock, using one of many ways to do it, and
while it may be an implementation detail, we can provide hints and
potential solutions to many ways of achieving it. Once we done that, we
will actually have both TAI and TAI-UTC knowledge, so as a side effect
we might as well distribute it along.

Now, if you know the current TAI-UTC difference, often you can apply
heuristics to the jump you see on an input clock. Problem is you are now
late with that knowledge and the ambition to distribute it before the
event. So, for that reason I view that observation is not very useful
for the problem at hand.

So I think we need to choose between two different scenarios, either one
where we allow multiple timescales being sent, without TAI-UTC
difference at all times, or we go for a unified timescale meeting the
ideal model properties, and say that we need to be able to resolve the
issue. There is no real way around that central question.

I lean towards pushing the conversion requirement onto the NTP source
nodes just to achieve the intended cleanness of the rest of the
infrastructure.

It is only as a side-consequence that I note that it will come with very
low additional cost to also provide the TAI-UTC difference as needed
when we have done that, but it is not my primary motivation although a
very nice positive upside. Thus, a nice secondary gain.

Cheers,
Magnus