Jan,
Jan Kasprzak wrote:
Hello,
thanks for the explanation. Few questions, though:
Martin Burnicki wrote:
: [email protected] 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 [email protected] 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:
ftp://tycho.usno.navy.mil/pub/ntp/leap-seconds.list
Unfortunately there are sometimes also problems with the NIST link:
ftp://time.nist.gov/pub/
However, a copy of the NIST file is available via the Meinberg web site
via https:
https://www.meinberg.de/download/ntp/leap-seconds.list
Recently the IERS who publishes Bulletin C also started to provide a
leap second file, which is also available via https:
https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list
: > - 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 [email protected] 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=147.231.2.6,
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 [email protected] 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,
expire=201512280000
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
--
Martin Burnicki
Senior Software Engineer
MEINBERG Funkuhren GmbH & Co. KG
Email: [email protected]
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
_______________________________________________
pool mailing list
[email protected]
http://lists.ntp.org/listinfo/pool
