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

[Magnus Danielson <[e-mail]>]

Ulrich,

On 2020-12-11 08:38, Ulrich Windl wrote:
>>>> Magnus Danielson <[e-mail]> schrieb am 10.12.2020 um 20:07 in
> Nachricht <[e-mail]>:
>> Ulrich,
>>
>> On 2020-12-10 07:59, Ulrich Windl wrote:
>>>>>> Miroslav Lichvar <[e-mail]> schrieb am 09.12.2020 um 14:46
> in
>>> Nachricht <20201209134612.GC2352378@localhost>:
>>>> On Wed, Dec 09, 2020 at 02:29:32PM +0100, Ulrich Windl wrote:
>>>>> 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.
>>>> There is the tzdist (RFC7808) protocol designed for that.
>>>>
>>>> NTP could distribute a leap‑second table (it already did it with
>>>> Autokey, right?), but isn't NTP about distributing current time,
>>>> rather than reconstructing time in the past or future?
>>> Hi!
>>>
>>> You all seem to have missed my point: In the recent past there was a lot
> of
>>> discussion and confusion what the LI (Leap Indicator) means:
>>> Leap second today, leap second at the end of the month, leap second soon.
> So
>>> having the definite time of the next leap event would all make this
> easier.
>>> Actually it could make the LI even obsolete.
>> No, not really. I did see that, but there is a subtle point to it.
>>
>> You have two scenarios:
>>
>> 1) You know the current TAI-UTC offset, and there is no know upcoming
>> offset.
>>
>> 2) You know the current TAI-UTC offset, and you know there is a upcoming
>> new offset introduced at Time T to become offset O.
>>
>> As you provide the T and O values, you need to know if those fields is
>> valid or not, for that you typically use a separate flag to indicate
> Actually no: if the T is in the past it's equivalent to "no leap event
> scheduled" (and vice versa).
>
>> that, rather than put restrictions on how to interpret those values to
>> mean that. So, I think it is provides a much better function to have
>> such a flag.
Do read the complete sentence. There is many ways to have values "flag"
things. Each such ends up being problematic in the long run.
>>
>> Separate from that, people have suggested that a flag should indicate a
>> particular occurrences time. Unfortunately, that has proven the source
>> of nasty bugs, and also, it can put implications of for how long before
>> it can be announced, and you end up knowing that you know there is an
>> upcoming leap second, but the distribution mechanism does not allow you
>> to announce it yet because it would be interpreted for the wrong time.
>> Whenever possible, it is therefore advisable to always supply the
>> time-stamp at which time the future event will occur, as it then leaves
>> no room for misinterpretation. In the similar sense, it is advisable to
>> not use interpretation of the fields to know if they provide a future
>> event or not, but only indicate the facts about the future event which
>> occurrence is flagged with a dedicated bit.
>>
>> Being able to compress things does not make it wise, in fact it has
>> turned out to be very unwise to do so, as it is not future-proof at all.
>>
>> So, this is why I advocate for a flag to indicate upcoming leap-second,
>> a field to indicate the current TAI-UTC difference, upon the flag being
>> set the values of future time-stamp and new TAI-UTC offset becomes valid
>> fields.
>
> The only disadvantage I see is that T seeds some extra bytes.

Which is a relatively light weight price to pay for a robust mechanism
these days.

You can check the size of the fields for GPS in IS-GPS-200L. That is
carried over a 50 baud data-channel, and while only allowed to transmit
every 12,5 min, it have provided a robust mechanism since it's introduction.

Cheers,
Magnus