3 ms·
Google shared some details about how they do leap smearing and the adjustments were smeared over a long enough time to be small enough to not affect their appli
by nocarrier 11y ago
Google shared some details about how they do leap smearing and the adjustments were smeared over a long enough time to be small enough to not affect their applications. They've been doing this for a while with no ill effects AFAIK. I'm aware of other people patching ntpd to do similar stuff as well.
If you can get the smear to be gentle enough to not affect your apps, it's a nice workaround for the general problem. There's just so many components running inside a modern infrastructure, and it's hard to get them all to behave correctly during a traditional 61-second-minute leap second transition.
And that 2012 leap second linux kernel bug was pretty epic. AFAIK, people who are smearing didn't experience it.
http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html http://googleblog.blogspot.com/2011/09/time-technology-and-l...
- X-Istence 11y agochrony has support for leap second smearing too. About to turn it on at work to avoid crashing stuff in the lab. The amount of stuff that still runs an older Linux kernel is insane...
- bashinator 11y agoWhat kind of lab?
- X-Istence 11y agoLarge ISP.
- phs2501 11y agoSmearing is not suitable for all applications, however. For example, anything requiring sub-microsecond precision (i.e. data acquisition) would require at least a 12-day smear to not fail its timing requirements. Such precison is well outside the realm of NTP but is not really a problem for PTP. I've worked on Linux systems that have done this; ~100ns synchronization was not uncommmon. (PTP, incidentally, got it right and specifies that its timescale is based on TAI, so it is continuous.)