On Wed, Jul 4, 2012 at 17:22 UTC, Scott Howard wrote:
On Wed, Jul 4, 2012 at 8:50 AM, Jimmy Hess <mysidia@gmail.com> wrote:
The NTP daemon could still provide a configuration option to not implement leap-seconds locally, or ignore the leap-second announcement received. So the admin can make a tradeoff favoring Stability over Correctness, of _allowing_ the local clock to become 1 second inaccurate for a short time after the rare occasion of a leap second; and step it or slew the local clock, eg include the leap second in the ordinary time correction, averaged over a period of time instead of a 1 second jump.
Unless I'm mis-reading things, it already does - of sorts.
I hope anyone implementing systems that depend on minutae of leap seconds does not rely solely on your reading, but actually tests by inconveniently setting their clock and ntpd leapfile to actually insert a leap second.
According to the ntpd website ( http://www.ntp.org/ntpfaq/NTP-s-algo-real.htm#AEN2499) :
That FAQ is woefully out of date. http://support.ntp.org/ has more current information. The best reference for a given ntpd version is the html docs included in the tarball for that version. Some widely-used versions' html documentation is archived at http://doc.ntp.org/
*The theory of leap seconds in explained in Q: 2.4.. In reality there are two cases to consider:
If the operating system implements the kernel discipline described in Section 5.2, ntpd will announce insertion and deletion of leap seconds to the kernel. The kernel will handle the leap seconds without further action necessary.
But exactly how it handles it is up to the kernel. Linux and FreeBSD essentially step the clock backward 1s at 23:59:60.0 UTC. At least one system (I believe it was NetBSD or OpenBSD) instead stalls the clock for 1s, though each reading of the clock during that period is greater than the prior, the delta is microscopic and not related to elapsed time within that second, but simply preserves ordering of events. Dr. Mills attempted to exhort kernel developers to implement leap seconds while keeping the system time ever-increasing, but that advice was largely ignored because of implementation difficulty. For example, when first considered, NTP kernel extensions had microsecond precision. The approach of adding a tiny amount with each reading would open the system up to problems if apps could read the clock more than 1 million times during the leap second. It's also ugly for a SMP kernel to maintain global state on the last clock reading across processors. Most systems offer a monotonic alternative to the wall clock, typically implemented as an uptime counter in nominal SI seconds (nominal as defined by hardware, as the monotonic clock is _not_ disciplined by ntpd or affected by steps (setting the wall clock to a particular value). Look for CLOCK_MONOTONIC in the documentation of clock_gettime. There are also interval-only timer facilities like timer_settime. The tools are at hand for those who understand the implications of clock steps (which can occur under circumstances other than leap seconds).
If the operating system does not implement the kernel discipline, the clock will show an error of one second relative to NTP's time immediate after the leap second. The situation will be handled just like an unexpected change of time: The operating system will continue with the wrong time for some time, but eventually ntpd will step the time. Effectively this will cause the correction for leap seconds to be applied too late. *
This is the historic behavior of ntpd, but after years of complaints, it was changed. ntpd 4.2.6 and later step the clock backward 1s at the scheduled insertion if using the daemon loop discipline (as opposed to the kernel loop discipline).
Linux does implement the "kernel discipline" (via ntp_adjtime), so the first option is what normally happens. However you can disable this with an ntpd config option ("disable kernel") or via ntpdc at which point I'm presuming it will fall back to the second option.
The second option still gives you a step, but using the -x option to NTPD will slew this step, giving a gradual correction to the 1 second difference.
That is incorrect. -x is often misunderstood -- it does not disable stepping entirely, it raises the "step threshold" from 0.128s default to 600s. When ntpd synchronizes the clock and determines the offset exceeds the step threshold, the clock is stepped to the correct time. So long as you manage to keep your clock within 10 minutes of correct, -x isn't terribly different from disabling steps, but that's not what it does. In particular, when ntpd using the daemon loop implements a leap second by stepping the clock backward one second, the step threshold (and hence -x) are not a decision factor -- the step is taken. Cheers, Dave Hart