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: [email protected] 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 _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
