Subject: Re: [Ntp] Leap second

From: Hal Murray <[email-masked]>
Date: Thu, 23 Jan 2020 15:52:32 -0800

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;
                }

Looks like it is responding with "I don't know" during the extra second. (but 
I didn't check carefully)

-- 
These are my opinions.  I hate spam.

---

From: Warner Losh <[email-masked]>
Date: Thu, 23 Jan 2020 20:54:04 -0700

> I didn't check carefully)

That was what I was thinking about...

Warner

-- 
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
>

---

From: "Ulrich Windl" <[email-masked]>
Date: Fri, 24 Jan 2020 10:00:35 +0100

>>> Hal Murray <[email-masked]> schrieb am 24.01.2020 um 00:52 in
Nachricht <[email-masked]>:

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

> ‑‑‑‑‑‑‑‑

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.

> ‑‑

---

From: Tony Finch <[email-masked]>
Date: Fri, 24 Jan 2020 14:47:36 +0000

> for the repeated last second of the day.

My understanding is that the leap indicator bits are not synchronized with
the leap second, so they can't be used to disambiguate the repeated
second.

https://mailarchive.ietf.org/arch/msg/ntp/5KD48S2BFAMemNx99zQSB83hOJ8

This isn't specified in the NTP RFC, but I believe the way it works in
practice is that ntpd tells the kernel about the leap indicator bits using
ntp_adjtime(STA_INS), then continues with the same leap indicator
bits through the leap second until a subsequent ntp_adjtime() returns
TIME_WAIT, at which point the leap indicator bits are cleared. When this
happens is related to ntpd's polling interval, and not coupled to the leap
second at all.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
democracy, participation, and the co-operative principle

---

From: "Seaman, Robert Lewis - (rseaman)" <[email-masked]>
Date: Fri, 24 Jan 2020 15:17:09 +0000

Just a reminder that UTC does not have repeated seconds, whatever POSIX says, or NTP implements. Seconds are interposed (or elided) as needed. UTC second number 61 in that minute is distinct from second number 60. Or second number 59 of one minute is immediately followed by second number 1 of the next. If you want different behavior, define or adopt a different time scale.

Rob Seaman
Lunar and Planetary Laboratory
University of Arizona
--

On 1/24/20, 7:48 AM, "ntp on behalf of Tony Finch" <[email-masked] on behalf of [email-masked]> wrote:

    

    Tony.

---

From: Warner Losh <[email-masked]>
Date: Fri, 24 Jan 2020 08:31:56 -0700

> 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

---

From: Warner Losh <[email-masked]>
Date: Fri, 24 Jan 2020 08:37:48 -0700

Just a reminder that neither NTP nor POSIX admit that leap seconds exist
wrt their time stamps, only via some auxiliary data path are they
grudgingly communicated. Since neither of them have a unique encoding for
the leap second, we're left with a repeated label for two seconds, or some
kind of 'gap' where time stands still (which effectively repeats the second
or, viewed in the frequency domain, has a large frequency shift).

UTC is a flawed standard that almost nobody implements completely
correctly. It was promulgated without due thought and care (the record is
clear on this) and now we're stuck with its new way of counting time
(nobody had 61 seconds in a minute before UTC). While it's handy to keep
the clocks aligned to the funky direction the earth points in, and thus
keep telescopes pointing well enough to find the stars they are looking
for, the number of places where people have botched translating it into a
useful implementation remain large and stand as a body of evidence that
points out its flaws... Sadly, we're stuck with it. The least bad option
for coping seems to be introducing a frequency error to paper over leap
seconds, at least judging by what industry does...

Warner

On Fri, Jan 24, 2020 at 8:17 AM Seaman, Robert Lewis - (rseaman) <
[email-masked]> wrote:

> Just a reminder that UTC does not have repeated seconds, whatever POSIX
> says, or NTP implements. Seconds are interposed (or elided) as needed. UTC
> second number 61 in that minute is distinct from second number 60. Or
> second number 59 of one minute is immediately followed by second number 1
> of the next. If you want different behavior, define or adopt a different
> time scale.
>
> Rob Seaman

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 27 Jan 2020 08:24:24 +0100

>>> Warner Losh <[email-masked]> schrieb am 24.01.2020 um 16:31 in Nachricht
> 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.

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

---

From: Martin Burnicki <[email-masked]>
Date: Mon, 27 Jan 2020 09:12:29 +0100

Rob,

Seaman, Robert Lewis - (rseaman) wrote:
> Just a reminder that UTC does not have repeated seconds, whatever
> POSIX says, or NTP implements. Seconds are interposed (or elided) as
> needed. UTC second number 61 in that minute is distinct from second
> number 60. Or second number 59 of one minute is immediately followed
> by second number 1 of the next. If you want different behavior,
> define or adopt a different time scale.
The problem is that operating systems don't know anything about seconds
numbered 60 or 61 since they only count seconds since an epoch, and some
runtime library has to convert it to calendar date and time.

Even if the number of the second since an epoch is repeated when a leap
second is inserted, it would not be a big problem if the system calls
commonly used to retrieve the system time would provide an associated
status.

If you read the time from a Meinberg PCI card in a fast loop across an
inserted leap second the you can also evaluate a status that indicates
which second is the inserted second, so conversion function can return a
second number 61 for that second.

A similar call which returns the current time plus the kernel time
status is also available on most Unix-like systems, but applications
normally don't use it because it takes longer to execute.

Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: [email-masked]
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy

---

From: Martin Burnicki <[email-masked]>
Date: Mon, 27 Jan 2020 09:31:59 +0100

Warner Losh wrote:
> On Fri, Jan 24, 2020 at 2:00 AM Ulrich Windl
> <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     >>> Hal Murray <[email-masked]
[...]
>     should just sent the "correct" response.

If the server didn't respond, the client could assume that the server if
offline. If it does respond, the client knows the server is alive, but
the result of this one packet exchange is ignored beause the server says
"don't use this one".

The original implementation of ntpd can easily cope with this and just
sends another request after the next polling interval. So this doesn't
hurt at all.

> Maybe not responding is proper, since there will be a retry in a second
> or so.

Hm, retry after a second would be very bad. There have been
implementations which did that and were considered abusive. Just doing
another poll after the usual interval should be sufficient.

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

That's exactly the problem, and the reason why this has been implemented
quite some time  ago, as proposed by Miroslav Lichvar. IMO this is a
very good idea.

> Thankfully the

If the other filter entries at the client side have only small offset
values then even a single huge offset could mess up the filter output.
With this workaround the huge offset doesn't even make it into the
filter, preventing the filter output from being messed up.

Even if the server sends "unsynchronized" for about 3 seconds over a
leap second event, each well-behaved client will at most get one such
response, in case the end of his poll interval (which should be at least
64 s) falls into the 3 s interval around the leap second. Statistically,
most clients should not even notice that the server behaves this way
because the poll before the 3s interval and next time after that interval.

Martin
-- 
Martin Burnicki

Senior Software Engineer