Re: [Ntp] Antw: [EXT] Re: New Version Notification for draft‑gruessing‑ntp‑ntpv5‑requirements‑03.txt

[Ulrich Windl <[e-mail]>]

>>> Miroslav Lichvar <[e-mail]> schrieb am 19.10.2021 um 10:17 in
Nachricht <YW5/KqAZdI+EmlTn@localhost>:
> On Tue, Oct 19, 2021 at 10:01:45AM +0200, Ulrich Windl wrote:
>> >>> Miroslav Lichvar <[e-mail]> schrieb am 18.10.2021 um 16:33
in
>> Nachricht <YW2FvUiaHC/hbxkG@localhost>:
>> 
>> ...
>> > Same for UTC vs TAI.
>> 
>> I thing the TAI offset (whole seconds) should be part of every NTPv5 timing

> packet. So we can keep the old timestamp format while providing TAI.
> 
> That's the Timescale Offset field in my draft. If the selected
> timescale is UTC or TAI, it contains the TAI‑UTC offset, or 0x8000 if
> unknown. The expectation is that client will request the timescale
> which it is using for timestamping of NTP packets.

Would it be allowable for a stratum-1 server to provide an "unknown TAI
offset" while still claiming to be "v5"?
It could be a challenge for systems like DCF-77 that do do provide a TAI
offset.
So maybe a special "refclock" (similar to the "PPS") would be needed to
provide the TAI offset from UTC only.
We have the leapseconds file, but updating it is still a manual task.

> 
>> Maybe NTPv6 will demand that TAI should be the new time base. Still we
would 
> need the offset to provide UTC and similar.
> 
> If all computer clocks were keeping time in TAI, or at least could
> convert all their timestamps to TAI, that would make sense. But I
> think it's more likely that UTC will stop leaping before TAI is
> adopted everywhere.

It depends how future OS time APIs will look like.

> 
> ‑‑ 
> Miroslav Lichvar