Re: [Ntp] Antw: Re: Leap second

[Martin Burnicki <[e-mail]>]

Warner Losh wrote:
> On Fri, Jan 24, 2020 at 2:00 AM Ulrich Windl
> <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
>     >>> Hal Murray <[e-mail]
[...]
>     > 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.

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.

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

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
> error filter will filter that out, but still...

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

MEINBERG Funkuhren GmbH & Co. KG
Email: [e-mail]
Phone: [phone]
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