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

[Miroslav Lichvar <[e-mail]>]

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.

> > 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.

-- 
Miroslav Lichvar