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 <st...@ntp.org> wrote: > > shawn wilson writes: >> On Jun 23, 2015 6:26 AM, "Nick Hilliard" <n...@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
