[Ntp] Antw: Re: Antw: [EXT] Re: Timescales

>>> Magnus Danielson <magnus@rubidium.se> schrieb am 09.12.2020 um 14:44 in
Nachricht <9ad5edd1-8794-6b55-ff9d-187fc77481a2@rubidium.se>:
> Ulrich,
> 
> On 2020-12-09 14:29, Ulrich Windl wrote:
>>
>>> 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.
> 
> A mechanism that works well conveys the current value, when an upcoming
> event is occurring and which direction it will be. That solves most of
> the practical problems. For back-dating purposes, which is more of an
> obscure corner-case, being able to also provide older parts of the
> leap-second history is nice, but rarely very useful.
> 
> A less useful but still helpful mechanism is when there is a pre-warning
> mechanism of upcoming event and indication when the event occurs. For
> this to fully function the current value needs to be supplied from the
> side, but from then the updates can be done correct if the node is
> operational during the pre-warning interval. The strength in providing
> the current value directly is that you instantly can be "on the right
> page, eh second" and the strength of the pre-warning system is that you
> in advance can know of the leap second. In GPS for instance, you have in
> practice over 5 months of pre-warning, and you get an indication of when
> the event will occur so you can even be non-operational during the event
> and as you wake up instantly provide the correct value even if the
> current value update can be slugish (12.5 min cycle for transmission).
> 
> So, a good and simple mechanism is to give the current TAI-UTC offset,
> then have a flag indicating up-coming leap-second event, give the
> system-timestamp for when this event occurs and the TAI-UTC offset as
> result of that leap-second insertion.
> 
> Piggybacking a historic leapsecond file transfer will always be a nice
> feature, but not strictly required if this is in place.

Hi!

That's why I wrote "or at least the relevant part of it", meaning whether
there will be a leap event withing the next six months or not. That's deinitely
not a lot of data. The only reason to send the full table would be having to
avoid parsing the table before sending.

Regards,
Ulrich

> 
> Cheers,
> Magnus
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org 
> https://www.ietf.org/mailman/listinfo/ntp 