Re: [Ntp] NTPv5: big picture

[Martin Burnicki <[e-mail]>]

Miroslav Lichvar wrote:
> 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.

Hm, IIRC ntpd provides the leap second warning via the protocol about 24
hours in advance, *if* that information is available from some source.
Shouldn't that be enough?

Also IIRC, PTP provides a leap second warning on 12 hours in advance.

The only limitation for NTPv4 (without Autokey) is that the current TAI
offset can't be provided, which can easily be improved by an extension
field.

> We should also add support for timestamps in a
> non-leaping timescale to support the less usual case of clocks keeping
> time in TAI.

I fully agree, but as I said before, I also think it should be done by
providing UTC by default, and a correction to derive TAI from it.


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