I became aware of Google’s Public NTP servers a couple of weeks back and tweeted this:
Link: Public NTP | Google Developers – https://t.co/9emvXYhEAV ~google NTP servers for public use~
— EtherealMind (@etherealmind) December 2, 2016
Johannes replied that these server use leap smearing and can cause problems. Which leads to the question, “What is leap smearing?”
Here’s how Google describes it in the Official Google Blog: Time, technology and leaping seconds:
The solution we came up with came to be known as the ‘leap smear.’ We modified our internal NTP servers to gradually add a couple of milliseconds to every update, varying over a time window before the moment when the leap second actually happens. This meant that when it became time to add an extra second at midnight, our clocks had already taken this into account, by skewing the time over the course of the day. All of our servers were then able to continue as normal with the new year, blissfully unaware that a leap second had just occurred. We plan to use this ‘leap smear’ technique again in the future, when new leap seconds are announced by the IERS.”
If you want another opinion, this PDF from Meinburg, a maker of NTP devices, appears to be a comprehensive discussion of the issue. Here’s an excerpt:
Pros and Cons of the Smearing Approach The disadvantages of this approach are: * During the smear interval the time provided by smearing NTP servers differs significantly from UTC, and thus from the time provided by normal, non-smearing NTP servers. The difference can be up to 1 second, depending on the smear algorithm. * Thus the smeared time received by clients also differs from true UTC, which may also have legal consequences for applications requiring correct legal time which is based on UTC or the local time derived from true UTC, or has to be traceable to UTC, e.g. billing for mobile phone calls which is aligned with certain second boundaries. However, for applications where it’s only important that all computers have the same time and a temporary offset of up to 1 s to UTC is acceptable, a better approach may be to slew the time in a well defined way, over a certain interval, which is called “smearing the leap second”.
The Etherealmind View
- The vast majority of systems do not need accurate clocks, so within one second is likely good enough.
- Delaying the NTP response by milliseconds over some period (a day seems common) is within the NTP drift tolerance and unlikely to cause problems.
- If you need hyper-accuracy you won’t be using Internet-based time sources. You will have your own clock hardware and have your own solutions planned for the leap second.
I can’t see anything to worry about. Tell me I’m wrong?