A backward step is a known issue and something that people are more comfortable dealing with as it can happen on any machine with a noisy clock crystal. Having 61 seconds in a minute or 86401 seconds in a day is a different story.
On Jun 23, 2015, at 8:37 PM, Harlan Stenn <stenn@ntp.org> wrote:
shawn wilson writes:
On Jun 23, 2015 6:26 AM, "Nick Hilliard" <nick@foobar.org> wrote:
Blocking NTP at the NTP edge will probably work fine for most situations. Bear in mind that your NTP edge is not necessarily the same as your
network
edge. E.g. you might have internal GPS / radio sources which could unexpectedly inject the leap second. The larger the network, the more likely this is to happen. Most organisations have network fossils and ntp is an excellent source of these. I.e. systems which work away for years without any problems before one day accidentally triggering meltdown because some developer didn't understand the subtleties of clock monotonicity.
NTP causes jumps - not skews, right?
Left to its default condition, ntp will step/jump a change in excess of 128msec.
If you want to slew the clock instead, a 1 second correction will take a little over 33 minutes' time to apply.
I don't understand why people believe that stopping ntpd for a few minutes while the leap second is applied will help. If the system clock keeps good time, it will *still* be about 1 second ahead when ntpd is restarted, and that will trigger a backward step which is fatal to a number of applications.
H