[Ntp] Antw: Re: Antw: Re: Leap second

["Ulrich Windl" <[e-mail]>]

>>> Warner Losh <[e-mail]> schrieb am 24.01.2020 um 16:31 in Nachricht
<CANCZdfqNVGiOdZncUkJD5yAR8DvCBiWRnNZei=[e-mail]>:
> On Fri, Jan 24, 2020 at 2:00 AM Ulrich Windl <
> [e-mail]> wrote:
> 
>> >>> Hal Murray <[e-mail]> schrieb am 24.01.2020 um 00:52 in
>> Nachricht <[e-mail]>:
>>
>> > Warner Losh said:
>> >> NTP timestamp repeats the last second of the day. Once without the leap
>> bit
>> >> set and then again with it set.
>> >
>> > Which bit is that?  I don't know of a single "leap bit" in the header.
>> >
>> > There is a 2 bit header field with: normal (no leap), and add+del (leap
>> > pending) states.  The 4th state is used for non‑in‑sync.  Assuming you
>> meant
>>
>> > "bits" rather than bit, then the on‑off is backwards.  I expect it to be
>> > sending leap‑pending for most of the day, then send normal (no
>> leap‑pending)
>>
>> > for the repeated last second of the day.
>> >
>> > ‑‑‑‑‑‑‑‑
>> >
>> > I just looked at some code and found:
>> >                 if (leap_sec_in_progress) {
>> >                         /* always send "not sync" */
>> >                         xmt_leap = LEAP_NOTINSYNC;
>> >                 }
>>
>> I wonder whether this makes much sense. Probably easy to implement, but
>> maybe
>> the server just should not respond during the leap second. Preferrable it
>> should just sent the "correct" response.
> 
> 
> And what, exactly, is the "correct" response? There's no unique encoding
> for the leap second as an ntp timestamp.

I think the problem is that the LI (Leap Indicator) is used for two different
purposes:
1) Leap second annopuncement (ahead of time)
2) Performing the leap second (Kernel clock status)

So the NTP timestamp needs extra state information being related to the exact
second as the POSIX-based time stamp is not pecifying the correct time.

> 
> Maybe not responding is proper, since there will be a retry in a second or
> so. But if there's any kind of skew between machines, a time exchange
> across a leap second is going to lead to a large error. Thankfully the
> error filter will filter that out, but still...

That was my other thought: Either delay the response until leap second is done
(which will consume a lot of memory in the daemon), and the response will be
discarded in the client most likely. So not responding may seem the better
decision, but still this might give the impression that there is a connectivity
problem with the server...

> 
> Warner