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

[Magnus Danielson <[e-mail]>]

Martin,

On 2021-01-05 17:24, Martin Burnicki wrote:
> Magnus Danielson wrote:
>> 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.
> I really wonder what the "NTPv4 type of leap second jumps" is. If the
> system supports leap seconds at all, at least ntpd just passes the leap
> second announcement to the kernel. And the daemon relies on the
> timestamps returned by the kernel.
>
> If the kernel handles this in a way we don't consider "appropriate",
> what could an NTP (or PTP or whatever) daemon do to fix it? Applications
> will still suffer from limitations of the operating system.

Sure. It's a multi-front battle.

With "NTPv4 type leap-second jump" i mean the way that the NTPv4 clock
ticks in combination with the leap second flag. It's not a very neat
format, even if it works. Alone it does not give us TAI-UTC difference,
but if we setup that correctly, we have padded the leap-second and a
good implementation can get things right.

>
>> 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.
> Agreed.
Good we have agreement on that.
>
>> 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.
> That's also fine, but by default it should IMO be possible to provide
> simple clients with time in a way as compatible as possible.

Indeed. I am confident that the client can be very simple and provide
the right time, even with leap seconds occurring.

>
>> 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.
> If a *simple* client needs to do this just to derive UTC (what's
> probably the case for most not telco devices) than it's a wrong approach
> to provide TAI and derive UTC from it.

Well, it may seem so at first, but if we taken on the burden of getting
TAI and TAI-UTC and transport that, the client can be very simple and
provide TAI, UTC, POSIX, LINUX, PTP, GPS time scale replicas using very
little code or complexity. The mappings provided will not require many
pages and it will be easy to implement them all.

Check your inbox for a separate example.

Cheers,
Magnus