[Pool] Leap second is coming

Martin Burnicki martin.burnicki at meinberg.de
Thu Apr 16 10:59:03 UTC 2015


Jan Kasprzak wrote:
> 	Hello,
> thanks for the explanation. Few questions, though:
> Martin Burnicki wrote:
> : lst_hoe02 at 79365-rhs.de wrote:
> : > Sorry for maybe asking the obvious but
> : >
> : > - How to check if ntp is configured with a leap second file? Must it be
> : > listed in ntp.conf or is there some default set?
> :
> : If you run "ntpq -c rv" and the output shows a "tai" value then ntpd has
> : read a leap second file. For example:
> :
> : pc-martin:/etc # ntpq -c rv
> : associd=0 status=0414 leap_none, sync_uhf_radio, 1 event, freq_mode,
> : version="ntpd 4.2.8p2 at 1.3316-o Wed Apr  8 08:20:36 UTC 2015 (3)",
> : processor="x86_64", system="Linux/3.16.7-7-desktop", leap=00, stratum=1,
> : precision=-23, rootdelay=0.000, rootdisp=7937.673, refid=shm0,
> : reftime=d8d9160e.2c2467ac  Wed, Apr 15 2015 18:53:34.172,
> : clock=d8d91616.da49a196  Wed, Apr 15 2015 18:53:42.852, peer=55606, tc=4,
> : mintc=3, offset=-0.053, frequency=0.000, sys_jitter=0.000000,
> : clk_jitter=0.019, clk_wander=0.000, tai=35, leapsec=201507010000,
> : expire=201512280000
> 	What is the best way to get the leap seconds file? The first
> URL in Google search results is apparently redirecting to itself:

I think the best/easiest way is to use wget or curl.

Potential problems I've encountered are:

1.) Temporarily not reachable: retry later or use a different server

2.) The name also resolves to IPv6 addresses, but your local network is 
IPv4 only: use "wget -4"

3.) Access is https only but wget can't validate the certificate: 
Configure wget so that it can validate the certificate, or use "wget 
--no-check-certificate", or use your favorite browser to download the 
file manually.

For those who are going to complain about using --no-check-certificate: 
This is as safe as downloading using a http or ftp link. ;-)

> http://www.ietf.org/timezones/data/leap-seconds.list

Indeed this URL doesn't seem to work right now, but used to work some 
time ago.

USNO provides a leap second file:

Unfortunately there are sometimes also problems with the NIST link:

However, a copy of the NIST file is available via the Meinberg web site 
via https:

Recently the IERS who publishes Bulletin C also started to provide a 
leap second file, which is also available via https:

> : > - Without a leap second file ntp will simply decide based on the
> : > majority of upstream ntp servers it it will pass the information or will
> : > it pass the information from the "*" upstream?
> :
> : ntpd 4.2.6 and newer requires a majority of configured upstream servers
> : to accept and send a leap second warning, *or* a refclock which can
> : provide it, *or* a current leap second file which supersedes both other
> : types of source.
> 	Apparently the majority of my upstream servers do not send
> the leap second info - at least my "ntpq -c rv" does not show the "tai" value:
> associd=0 status=061b leap_none, sync_ntp, 1 event, leap_event,
> version="ntpd 4.2.8 at 1.3265-o Wed Dec 24 11:18:58 UTC 2014 (1)",
> processor="x86_64", system="Linux/xxx-gentoo", leap=00, stratum=2,
> precision=-23, rootdelay=4.481, rootdisp=32.150, refid=,
> reftime=d8d9d764.d4be8e2e  Thu, Apr 16 2015  8:38:28.831,
> clock=d8d9daa4.cc61c706  Thu, Apr 16 2015  8:52:20.798, peer=36704,
> tc=10, mintc=3, offset=0.185567, frequency=17.438, sys_jitter=0.130071,
> clk_jitter=0.164, clk_wander=0.013

Usually the tai value is only set if the local ntpd has read a local 
copy of the leap second file.

Eventually this is also the case if the leap second table has been 
passed down from an upstream server via the autokey protocol. However, 
this works *only* if both the server and the client are using autokey 
and have been configured properly. I have to admit that I've never tried 
autokey with regard to the passing the leap second table on to clients.

So your ntpd doesn't seem to have a leap second file, or hasn't been 
configured correctly to use the file, if it is available. See also the 
syslog messages generated when ntpd starts up.

Using a leap second file is important for NTP stratum 1 servers using 
refclocks. As reported here on the list, there are 3rd party GPS 
receivers out there which provide faulty announcements of a leap second, 
there are serial protocols like NMEA which AFAIK don't include a leap 
second warning flag, and thus are unable to pass a leap second warning 
to ntpd, and there are time sources which only provide a leap second 
announcement very late (e.g. 1 hour for DCF-77, a few seconds for IRIG 
time codes).

In these cases using a current leap second file can help to get it 
working. Please note, though, than in case of faulty GPS receivers, 
there may be an additional problem if the GPS receiver has already 
*applied* the leap second internally, and thus already outputs a time 
which is off by 1 s.

> 	How can I tell which upstream servers announce the upcoming
> leap second?

NTP servers provide its clients with a leap second announcement flag in 
the NTP packet sent to the clients. However, this flag is only set about 
24 hours before the leap second occurs. This means you don't see this 
right now, but you should see it on June 30 UTC.

While an NTP node has accepted a leap second announcement it reports 
this in the "leap" bits displayed by "ntpq -c rv".

On a test system here, if I run a leap second simulation, this looks like:

~ # date -u; ntpq -c rv
Tue Jun 30 23:47:18 UTC 2015
associd=0 status=4419 leap_add_sec, sync_uhf_radio, 1 event, leap_armed,
version="ntpd 4.2.8p1 at 1.3330-o Mon Mar 30 09:33:55 UTC 2015 (1)",
processor="i586", system="Linux/3.7.1", leap=01, stratum=1,
precision=-18, rootdelay=0.000, rootdisp=474.732, refid=MRS,
reftime=d93da906.00d96445  Tue, Jun 30 2015 23:47:18.003,
clock=d93da906.1e08fc00  Tue, Jun 30 2015 23:47:18.117, peer=52969, tc=3,
mintc=3, offset=34.848942, frequency=160.724, sys_jitter=2.118422,
clk_jitter=10.744, clk_wander=0.000, tai=35, leapsec=201507010000,

See the date, 2015-06-30, and "leap=01" in the output.

> : If your server has a leap second file and inserts the leap second, but
> : the upstream servers you have configured don't insert the leap second
> : then your server will observe a 1 s offset after the leap second and,
> : and will re-synchronize to the upstream server(s) a few minutes later,
> : i.e. step the time to be wrong like the servers.
> 	So it is better to not have the leap seconds file configured,
> when my upstream servers do not announce the tai offset?

You don't need it in this case, but you can use it.

A leap second file contains a table of *all* leap seconds, and the TAI 
offset after each leap second. So if ntpd can use/read the leap second 
file it can tell the true current TAI offset. However, the TAI offset is 
not *required* for proper operation. Ntpd just gets the last recent leap 
date from the file and starts to send a leap second warning to its 
clients (and also handles the leap second for its own system time) when 
the leap date is approaching.

The NTP network protocol only provides an announcement flag that a leap 
second is to be applied at the end of the UTC day. If the server sends 
the announcement correctly then this is sufficient to let the clients 
insert the leap second correctly. Of course in this case the TAI offset 
may not be correct since not all table entries are available, but that 
doesn't matter.

I just mentioned the tai variable as a hint how you can easily check if 
the running ntpd is using a leap second file, or not.

Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burnicki at meinberg.de
Phone: +49 (0)5281 9309-14
Fax: +49 (0)5281 9309-30

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, 
Andre Hartmann, Heiko Gerstung
Web: http://www.meinberg.de

More information about the pool mailing list