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
