[181420] in North American Network Operators' Group
Re: REMINDER: LEAP SECOND
daemon@ATHENA.MIT.EDU (Harlan Stenn)
Tue Jun 23 20:39:14 2015
X-Original-To: nanog@nanog.org
From: Harlan Stenn <stenn@ntp.org>
To: shawn wilson <ag4ve.us@gmail.com>
In-reply-to: <CAH_OBicDvkRjzHoyoVNZws9e2R0U8R-rtYiy5N8sS=np6zWjJw@mail.gmail.com>
Date: Wed, 24 Jun 2015 00:37:51 +0000
Cc: North American Network Operators Group <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
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
