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

[Magnus Danielson <[e-mail]>]

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.

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. With this, you are in the heads-up part of solution space
already for servers, which is similar enough to knowing coming and
current leap-second difference (a leap-second file achieves the
difference, and update of that or through leap-second indications).

So, in the end I am not very convinced.

>
>>> It makes sense to require servers to convert the timestamps if they
>>> have the offset, but for some hardware implementations (one-step
>>> clocks) that might not be possible.
>>>
>> What one-step clocks would that be? Surely, I expect none of the
>> existing NTP clocks to automatically support NTPv5, almost regardless
>> which shape it will take.
> If the transmit timestamp in the NTPv5 packet is at the same location
> as in NTPv4 and has the same meaning, as it is in my proposal, the
> same hardware can be used for timestamping NTPv4 and NTPv5 packets.
> It doesn't need to know anything about the packet itself, just that it
> is supposed to put the timestamp there.
>
Now, others have already raised that they want a TAI-like time-stamp
format. The reason is that the POSIX-like properties makes core
algorithms a bit more complex. It's not aiding to make a simple client
being simple.

Cheers,
Magnus