[ntp:questions] WARNING: someone's faking a leap second tonight
martin.burnicki at meinberg.de
Sun Aug 5 10:49:44 UTC 2012
E-Mail Sent to this address will be added to the BlackLists wrote:
> Martin Burnicki wrote:
>>> clients to independently set LI=00 during, say the first
>>> half of the month, and to ignore the LI value from
>>> servers during that time.
> I think you would have to be more exact than that.
> LI is used for more than one thing.
> According to the doc, LI only applies to the current day?
If we are going to discuss this absolutely in detail the even more things
need to be taken into account, e.g. where the leap second warnings come
from, how long they persist, and how they are passed to NTP.
E.g. the GPS satellites usually start to send information about an upcoming
leap second about 6 months before the leap second event actually occurs,
shortly after the IERS has sent its bulletin C which announces this. The
sats don't simply send a warning flag but the exact UTC time *when* this is
going to happen. So GPS receivers know about the leap second long before it
becomes interesting for NTP.
It depends on the GPS receiver at which time it starts to output a leap
second warning so ntpd can become aware of it, which protocol is used to
pass GPS time to NTP, and if the selected protocol even supports leap
second warnings. Correct me if I'm wrong, but as far as I know there is
e.g. no NMEA sentence providing a leap second warning before the leap
second actually occurs. For operation with NTP it is not sufficient just to
send second 60 *during* the leaps second, i.e. when the leap second is
already in progress.
On the other hand there are string formats supported by the parse river
(driver 8) which do support this.
The German longwave transmitter DCF77 starts to send out a leap second
warning flag only 1 hour before the leap second occurs. This interval may
be long enough to provide the leap warning for stratum 1 and eventually
stratum 2 servers, but it is probably too short for clients at a lower
stratum level if large polling intervals are used, simply because the worst
case summary of polling intervals exceeds the announcement interval.
If IRIG signals are used for refclocks then things are even worse since most
IRIG frame formats don't even support leap second warnings. Only IRIG
formats with extension IEEE 1344 or its successor, IEEE C37.118 support
this, but the announcement interval is only 1 minute or so, which is
definitely to short to pass a leap second warning reliably from an IRIG
controlled stratum-1 NTP server down to a chain of secondaries and clients.
So in some cases like this a leap second file (which needs to be updated
regularly) should at least be a way to get the leap second be handled
On the other hand, if you are using a GPS receiver and a serial string
format providing ntpd with a leap second warning early enough, then you
don't have to care about leap seconds since the GPS receiver gets the
warnings from the satellites, and you don't have to worry if your leap
second file is updated regularly.
If it comes to NTP then you should always mention the version of NTP you are
talking about since the behaviour of leap second handling has changed
across versions, e.g.
- when ntpd starts to accept a leap warning
- from which sources it accepts a leap warning under which conditions: from
a single upstream server (earlier NTP versions) or only from a majority
(current NTP versions), from refclocks, from a leap second file, and which
priorities come into effect if there are upstream servers *and* one or more
refclocks *and* a leap second file, or another combination of those.
- which plausibilty checks ntpd does to avoid erraneaous leap second
warnings: earlier NTP versions inserted a leapsecond only at the end of
June or the end of December, but supported also leap second deletions which
could occur in theory and can also be warned about by GPS, while current
versions of ntpd accept leap second warning for the end of *any* month, but
(as far as I know) don't support leap second deletion anymore at all.
Of course, all of the above is valid only in the absence of firmware bugs or
NTP bugs which can mess up everything.
More information about the questions