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

[Magnus Danielson <[e-mail]>]

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.

Cheers,
Magnus