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

[Martin Burnicki <[e-mail]>]

Magnus Danielson wrote:
> Miroslav.
> 
> On 2021-01-07 12:25, Miroslav Lichvar wrote:
>> On Wed, Jan 06, 2021 at 12:53:06AM +0100, Magnus Danielson wrote:
>>> I'm not at all convinced. PTP has little, at least as I can see in
>>> IEEE1588-2008, that really supports the UTC with time-stamps. I should
>>> check IEEE1588-2019 for more details, but you will have to explain very
>>> clearly how that support comes about in PTP, because as I see it, if you
>>> run UTC only it's hand-wavey at best. If you can show clearly how PTP
>>> handles UTC and especially as a leap-second occur without hickup.
>> PTP has the arbitrary timescale, which is typically used for a UTC
>> transfer when serving time from an OS clock (as opposed to a hardware
>> clock). It also has a leap announcement bit. That's all what is
>> needed to synchronize two UTC clocks without knowing the TAI-UTC
>> offset. It can work exactly the same as NTPv4.

Yes, but the arbitrary timescale is only *typically* used for a UTC, it
can also mean something else. So PTP isn't distinct in this case, either.

> OK, I can accept that considering heads-up is provided as needed per
> IEEE1588 and that the UTC to time-stamp mapping is found that details
> how UTC 23:59:60 is time-stamped and progressed. How will be know the
> actual UTC read-out from such as setup?
> 
> The leap second announcement needs to be at least two announce messages
> before, so you need to have heads up information about the upcoming
> leap-second.

If I remember correctly, the leap second warning is sent by the
grandmaster 12 hours in advance, *if* the information is available.

If there's a faulty leap second warning from the time source, the
grandmaster has the same problem as an NTP server that has received a
faulty warning.

And if the PTP slave passes the leap second warning to a Linux kernel so
that the Linux kernel can update its CLOCK_REALTIME at the right opint
in time, applications that are based on UTC/local time will encounter
exactly the same problem as with NTP.

So from this point of view (the use case for applications), there's not
much advantage on using TAI timestamps for the protocol.


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