[Ntp] Antw: [EXT] Re: Timescales

>>> Miroslav Lichvar <mlichvar@redhat.com> schrieb am 09.12.2020 um 12:30 in
Nachricht <20201209113003.GA2352378@localhost>:
> On Wed, Dec 09, 2020 at 02:18:30AM ‑0800, Hal Murray wrote:
>> Given TAI, there are 2 pieces of information that a clients needs to handle

>> UTC and its leap seconds.  The first is the current TAI‑UTC offset.  The 
>> second is when the next leap second happens.  That data changes very 
>> infrequently and with plenty of warning.  There is no need to clutter up 
>> on‑the‑wire protocols with it.  A client could get it from a leap‑seconds
file 
>> distributed by their distro.
> 
> Relying on a separate source like the leap‑seconds file is not always
> possible. The device may not have an up‑to‑date OS, or actually have
> any writable memory to store that information.
> 
> There is definitely not a plenty of warning. Some reference clocks
> give the leap announcement only an hour before it happens (e.g.
> DCF77). Even delaying setting of the kernel leap status to the clock
> update can be a problem if you are polling at 1024 seconds and have
> more than two measurements dropped in a row in the clock filter.

However you could see the leap indication flag also as "leap confirmation"
flag (actually there will be a leap event). With only DCF-77 clocks this could
be a problem. As said earlier, it would be best if NTP could reliably transfer
the leapsecond table, or at least the relevant part of it to make clients know
in advance that and when a leap event is scheduled.

Regards,
Ulrich

> 
> ‑‑ 
> Miroslav Lichvar
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org 
> https://www.ietf.org/mailman/listinfo/ntp 