Re: [Ntp] Antw: Re: Leap second

[Warner Losh <[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.

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...

Warner