Re: [Ntp] NTPv5: big picture

[Miroslav Lichvar <[e-mail]>]

On Tue, Jan 05, 2021 at 03:41:55PM +0100, Magnus Danielson wrote:
> Hi,
> 
> On 2021-01-05 09:54, Miroslav Lichvar wrote:
> > On Mon, Jan 04, 2021 at 01:20:55PM -0700, Philip Prindeville wrote:
> >> PTP uses TAI.  It doesn’t seem to have been an impediment for them.  What am I missing?  And how did these “good technical reasons” not apply here?
> > PTP doesn't support TAI only. It supports TAI and an "arbitrary"
> > timescale. TAI is used for synchronization of hardware clocks, which
> > is the primary use case of PTP. If you wanted to synchronize a system
> > clock with PTP, the timestamps would typically be in the arbitrary
> > timescale (UTC).
> 
> PTP actually support both providing a TAI and UTC replica, as it also
> carries the TAI-UTC difference in addition to having the core time-stamp
> format that derives from TAI.

It does provide the TAI-UTC offset, but it is optional. There is a
flag to indicate the value is valid. PTP supports operation in
UTC-only and TAI-only environments.

> Regardless how we turn, we can not push the leap-seconds completely off
> the table. They need to be handled up front. If so, they can be handled
> fairly OK, where as trying to ignore them just create a number of
> problematic side-cases. I know what I prefer based out of my experience
> of building timing systems.

I think the problems of NTPv4 wrt leap seconds are well understood.
We need to announce leap seconds earlier and provide the TAI-UTC
offset if known. We should also add support for timestamps in a
non-leaping timescale to support the less usual case of clocks keeping
time in TAI.

--  
Miroslav Lichvar