[LEAPSECS] Leap seconds have a larger context than POSIX

[Martin Burnicki]

Tom Van Baak wrote:
> Hi Hal,
> 
> It's 2020. How on earth can NTP still not implement UTC correctly, in
> all cases? Or is it a fundamental NTP design flaw?

A program like ntpd (or ptpd, FWIW) has to rely on available sources of
information, and if those sources provide wrong information, this can
produce wrong results.

Of course there can be (and have been) bugs in the way ntpd handled leap
seconds. However, I'm not aware of any bufg in the current ntpd code.

Originally ntpd accepted a leap second from any upstream source that
announced it, and forwarded the announcement to its clients.

However, after it had happened that some GPS receiver models had sent a
faulty leap second announcement which the server forwarded to its
clients, the code in ntpd was modified in a way that a client accepts a
leap second announcement only if a majority of its upstream servers
provides the announcement.

If you implement a plausibility check that accepts leap second only at
the end of June or December, you avoid (at the first glance) that your
server's time is messed up if a faulty device sends an announcement at
the end of the wrong month.

But what if your GPS receiver sends a wrong leap second announcement at
the end of December, when there is no real leap second, or does *not*
send an announcement if a leap second has been scheduled?

If the GPS receiver which sends a wrong leap second announcement also
applies the leap second to its internal time, then the time sent by the
receiver is off by 1 s after the false leap second event.

What should a program do that has the GPS receiver as its sole time
source? Stop synchronizing to the receiver, or follow the time step
after some time if the 1 s offset persists?

What if the GPS satellites start sending data that cause the UTC
correction by GPS receivers to be 13 microseconds off? Is NTP to blame
if it follows the GPS receiver's time?

Which is the offset range that should be accepted if an "authoritative"
time source like a GPS receiver starts sending a different time?

So I wonder why NTP (the protocol) or ntpd (the implementation) are
blamed here. There's a lot of stuff in there which tries to sort out
errors coming from external time sources, but I doubt there can be an
implementation which is in no way affected by any potential error from
outside.


Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burnicki at meinberg.de
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