Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

HOWTO prepare ntpd to the leap of a second

123 views
Skip to first unread message

Serge Bets

unread,
Dec 22, 2005, 3:30:18 PM12/22/05
to
Hello,

I would like a review of this nano-HOWTO prepare ntpd to the leap of a
second. Any comments and enhancements are welcome. Especially reports on
different ntpd versions. And any ideas about automated refreshing of the
NIST file twice a year in a way that must be network friendly, NIST
servers friendly, and secure. Is there some https://URL to get only
"If-Modified-Since:"?


------------------------------------------------------------------------
HOWTO prepare ntpd to the leap of a second

This procedure uses the NIST leap-seconds file to inform the NTP daemon
about the absence or existence of an upcoming leap second event. It
cooperates well with any sync source(s) you may use, even if they convey
good, wrong, late, or no leap bits at all. The NTP daemon will always
serve clean leap bits to its downstream clients, around 1 month before
the event.

Step-by-step procedure: On your master NTP server(s), do as root:

0) If you use autokey authentication, cd to the keysdir directory, and
goto step (3).

1) Create an /etc/ntp directory, cd there, and create host parameters
(as if you were using autokey feature):

| # mkdir /etc/ntp
| # cd /etc/ntp
| # ntp-keygen -H -p password


2) Add to ntp.conf those two lines:

| keysdir /etc/ntp
| crypto pw password


3) Download the NIST leapseconds file leap-seconds.3331497600 (or
latest) from ftp://time.nist.gov/pub/ by passive ftp.


4) Make a symlink from the generic name ntpkey_leap to the file:

| # ln -s leap-seconds.3331497600 ntpkey_leap


5) Restart the NTP daemon. After it is synced, you can verify all worked
well using the ntpq readvar command, by looking at the date of last
modification of the data, and checking the current TAI offset:

| $ ntpq -c "rv 0 leapsec,tai"
| assID=0 status=4234 leap_add_sec, sync_lf_clock, 3 events, event_peer/strat_chg,
| leapsec=200507280000, tai=32


Notes:
- Some older ntpd used "leapseconds" variable giving the NTP timestamp,
instead of "leapsec" printing a human readable date.
- Before the NTP daemon is synced for the first time, it is normal to
see tai=0, because the current date is not yet known for sure.
- You can apply this procedure on all hosts running ntpd, only on
servers, or even only on your clique of lowest stratum master servers.
In any case the leap bits will flow down on clients. And additionally,
if you use autokey, the data in the file (not the file itself) will be
sent to the authenticating clients, with the implied TAI offset.
- NIST leap-seconds file has an expiration date, currently 28 June 2006
which is 2 days before the following possibility of a leap second event.
Make sure to refresh the file before this date, at anytime between
February and May 2006.
- Orphan mode in some conditions breaks leap bits.
- This procedure is tested with ntp-dev-4.2.0b-20051208.tar.gz version
on Linux, and ntp-dev-4.2.0b-20051105-nt.zip on Windows.
------------------------------------------------------------------------


Thankfully, Serge.
--
Serge point Bets arobase laposte point net

David L. Mills

unread,
Dec 22, 2005, 9:08:02 PM12/22/05
to
Serge,

I can't speak for previos ntpd versions since the last leap event at the
end of 1998, but I can say the current version here does correctly
insert the leap.

Be advised, as in many previous posts, the kernel must include
provisions to implement the leap. The ntpd does not actually do the
leap, just tell the kernel to do it. So far as I know, FreeBSD, Linux,
Solaris and Tru64 (ALpha) have the code from me. While FreeBSD and
Solaris have it in the released code, others may have to patch or
recompile the kerel. I know HP-UX does not have those functions,
although I implemented them for that system many years ago.

Plan A: Fetch the leapseconds file from time.nist.gov and install in the
same place the Autokey files are stored. Autokey must be running in
order to load that file so the leap bits can be correctly set.

Plan B: Rely on upstream servers to set the leap bits. If any of them
set the bits, your machine will set the bits. Be advised, the NIST and
USNO servers I poked just now do not at this time set the bits. The Udel
servers pogo, rackety and louie shine the bits properly now.

Plan C: If running Autokey with one or more upstream servers with the
leapseconds file, the file will be automatically loaded in your machine.
This is so your applications can see the bits and TAI offset in the
ntp_gettime() call.

The Autokey protocol is restarted automaticall once each day and
refreshes the leapseconds file, but only from the direct upstream
server, which may or may not have the file. Currently, neither NIST nor
USNO run Autokey. A script can easily hijack the file by ftp from NIST,
but this is not a matter for NTP.

Dave

Danny Mayer

unread,
Dec 23, 2005, 1:00:30 PM12/23/05
to
Serge Bets wrote:
> Hello,
>
> I would like a review of this nano-HOWTO prepare ntpd to the leap of a
> second. Any comments and enhancements are welcome. Especially reports on
> different ntpd versions. And any ideas about automated refreshing of the
> NIST file twice a year in a way that must be network friendly, NIST
> servers friendly, and secure. Is there some https://URL to get only
> "If-Modified-Since:"?
>

Here's the proper procedure:

1) Go to local liquor store and purchase a champagne of a make and
vintage that you enjoy.

2) Placee bottle(s) in refrigerator to ensure proper cooling.

3) 10 minutes before midnight UTC, remove chamgagne from refrigerator,
open and let stand for a few minutes to let it breathe.

4) Pour for yourself and anyone else who may be with you into glasses.

5) Run ntpq -p -c rv in a loop and watch current time.

6) At leap-second insertion time raise glasses and toast the UTC New Year.

7) Go to bed if late, local time.

Happy new leap-second.

Danny
_______________________________________________
questions mailing list
ques...@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Terje Mathisen

unread,
Dec 23, 2005, 3:18:56 PM12/23/05
to
Danny Mayer wrote:

> Serge Bets wrote:
>
>>Hello,
>>
>>I would like a review of this nano-HOWTO prepare ntpd to the leap of a
>>second. Any comments and enhancements are welcome. Especially reports on
>>different ntpd versions. And any ideas about automated refreshing of the
>>NIST file twice a year in a way that must be network friendly, NIST
>>servers friendly, and secure. Is there some https://URL to get only
>>"If-Modified-Since:"?
>>
>
>
> Here's the proper procedure:
>
> 1) Go to local liquor store and purchase a champagne of a make and
> vintage that you enjoy.
>
> 2) Placee bottle(s) in refrigerator to ensure proper cooling.
>
> 3) 10 minutes before midnight UTC, remove chamgagne from refrigerator,
> open and let stand for a few minutes to let it breathe.
>
> 4) Pour for yourself and anyone else who may be with you into glasses.
>
> 5) Run ntpq -p -c rv in a loop and watch current time.
>
> 6) At leap-second insertion time raise glasses and toast the UTC New Year.
>
> 7) Go to bed if late, local time.
>
> Happy new leap-second.

<BG>

All the talking about leap seconds caused me to check the status of my
reference clocks, I noted back in october/november that none of them had
set the leap_sec flag.

Now in december, things had changed:

All my new FreeBSD 6.0 + Synergy Systems Oncore servers agreed that yes,
indeed, a leap second is imminent.

The same did my FreeBSD 6/Garmin OEM 18 NMEA server, while my original
TAPR-sourced DIY 8-channel Oncore UT+ (running on V5.3) was the only one
which still didn't acknowledge leap_add_sec.

At this point I followed Serge Bets' nice HowTo post, installing crypto
certificates and the leapseconds file. After an ntpd restart everything
was fine, including the TAI offset which none of the other systems are
handling.

The only stumbling point was a problem running

ntp-keygen -H -p password

which failed, complaining about a missing /root/.rnd file.

I cat'ed about 10 MB from /dev/random into this, and this was sufficient
to make ntp-keygen happy. I guess a softlink would have been easier and
better?

Terje

--
- <Terje.M...@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

Hal Murray

unread,
Dec 23, 2005, 6:42:09 PM12/23/05
to
>The same did my FreeBSD 6/Garmin OEM 18 NMEA server, while my original
>TAPR-sourced DIY 8-channel Oncore UT+ (running on V5.3) was the only one
>which still didn't acknowledge leap_add_sec.

Is that box getting any leap warning info from the Garmin?

I scanned the manual and couldn't find any warning - only a section
saying that it will repeat the 00 seconds timestamp at midnight.

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.

Terje Mathisen

unread,
Dec 24, 2005, 4:38:38 AM12/24/05
to
Hal Murray wrote:

>>The same did my FreeBSD 6/Garmin OEM 18 NMEA server, while my original
>>TAPR-sourced DIY 8-channel Oncore UT+ (running on V5.3) was the only one
>>which still didn't acknowledge leap_add_sec.
>
>
> Is that box getting any leap warning info from the Garmin?

Probably not.


>
> I scanned the manual and couldn't find any warning - only a section
> saying that it will repeat the 00 seconds timestamp at midnight.


Right, I suspect that this box, running the latest & greatest ntp-dev
code was capable of picking up the leap warning from one of the
Oncore-based peers.

Harlan Stenn

unread,
Dec 24, 2005, 4:09:34 PM12/24/05
to
I'm now wondering how ntpd will handle the "problem" of the case where it
gets the time from a leap-unaware refclock *during* the leap second (given
that other leap-aware sourced of time are available).

I suspect it will simply be thrown out as a bad sample.

I also suspect I am not awake enough to be contemplating such things...

H

Serge Bets

unread,
Dec 23, 2005, 3:49:19 PM12/23/05
to
Hello David,

On Friday, December 23, 2005 at 2:08:02 +0000, David L. Mills wrote:

> the kernel must include provisions to implement the leap. The ntpd
> does not actually do the leap, just tell the kernel to do it.

First much thanks for all the infos. I was focused on the NTP leap bits,
not the way kernels are informed and do the leap. I'll add a paragraph
about that.


> Autokey must be running in order to load that file so the leap bits
> can be correctly set.

Yes. In some way loading the NIST file has an interest even outside of
Autokey, and those functions could be less dependant. It would benefit
to ease of use, and permit the file features even --without-crypto. Note
that's just loud thinking, not a suggestion.


> Plan B: Rely on upstream servers to set the leap bits.

This is the default plan, when user does nothing special. It may fail,
for a variety of reasons like no leap bits in MSF radio, too late
announcement, or the spurious insertion announced some monthes ago at a
wrong date by some buggy GPS receivers.

I like to think to plan A as a way to cleanup those maybe wrong upstream
leap bits. Again loud thinking, that could mean use file and totally
ignore upstream, until the file expires. Then resume confidence to
upstream. Unless the notified operator has refreshed the file.

Hum... This would need at loading to extract the expire date from file,
and in Autokey to make use of it as fs, instead of modification date. So
that files with 6 monthes extended validity but no new leap event get
transmitted to Autokey peers as beeing newer. Don't know if it would be
feasable at all.


> The Autokey protocol is restarted automaticall once each day and
> refreshes the leapseconds file, but only from the direct upstream
> server

What do you mean? The leapseconds file is not refreshed in cascade up
the stratums? Or is it lost at each Autokey restart?

David L. Mills

unread,
Dec 24, 2005, 8:36:26 PM12/24/05
to
Serge,

Scarfing the current leapsecond file from NIST should not be a problem
with a shell script and cron job. If Autokey is enabled, even with no
server marked to use it, the file will be loaded and the leap bits set
accordingly. If Autokey is running with a number of servers, only the
latest data are used. Since old leap epoches don't change, the only
thing that can happen is the addition of a new epoch at the next
opportunity.

With Autokey each association is restarted once per day, so the latest
leapsecond data will be retained from each server. If those servers do
the same thing, it may take a few days for the data to flow from an
authoritative source.

Dave

David L. Mills

unread,
Dec 24, 2005, 8:51:30 PM12/24/05
to
Harlan,

From the survivors of the clustering algorithm the protocol runs an
agreement algorithm. The simplest one implemented lights the host leap
bit if any survivor leap bit is lit. You should be able to work out the
many scenarios that can occur.

Dave

Serge Bets

unread,
Dec 27, 2005, 8:26:22 AM12/27/05
to
Hello David,

On Sunday, December 25, 2005 at 1:36:26 +0000, David L. Mills wrote:

> If Autokey is running with a number of servers, only the latest data
> are used. Since old leap epoches don't change, the only thing that can
> happen is the addition of a new epoch at the next opportunity.

Another thing could happen: IERS decision of *no* leap second insertion
at the next opportunity. Result for leap-seconds file is then:

- Unchanged events table.
- Unchanged lastmod timestamp.
- Unchanged filename extension.
- Expiration timestamp pushed by 6 monthes.

| $ awk '/^#@/{print $2}' leap-seconds.3331497600
| 3360441600

This is currently the NTP timestamp of 28 June 2006. Sometime early
January 2006, IERS would decide to not brake the Earth, and thus no leap
second insertion will be necessary on 30 June. They would announce it in
their bulletin C29. Sometime later in January 2006 NIST would update the
leap-seconds.3331497600 file, with one change only: Expiration date
advanced to 29 December 2006.

The NIST file is absolutely true until expiration. This fact is not
exploited by the NTP daemon, but could perhaps be.


> With Autokey each association is restarted once per day, so the latest
> leapsecond data will be retained from each server. If those servers do
> the same thing, it may take a few days for the data to flow from an
> authoritative source.

OK: Thanks for the confirmation. I had misunderstood your previous
explanation.


Thankfully, Serge.

David L. Mills

unread,
Dec 29, 2005, 9:16:09 AM12/29/05
to
Serge,

I don't understand your concern. The existing code inspects the
leapsecond file and considers the latest entry. If that entry is in the
future the leap bits are set. Otherwise not. This assumes the file is
updated following the most recent insertion opportunity. As the current
file is dated in July and specifies a leap insertion at the end of this
year, this condition is satisfied. The rationale for that is included as
comments in the file itself.

Dave

Serge Bets

unread,
Dec 29, 2005, 3:56:08 PM12/29/05
to
On Thursday, December 29, 2005 at 14:16:09 +0000, David L. Mills wrote:

> Serge Bets wrote:
>> The NIST file is absolutely true until expiration. This fact is not
>> exploited by the NTP daemon, but could perhaps be.

> I don't understand your concern.

The NTP daemon will not assert leap=00 against any bogus source wrongly
saying leap=01 during June 2006.

The authority of the soon updated NIST leapseconds file, expiring only
later on 29 December 2006, thus valid, and showing no leap event on
30 June 2006, could perhaps be used to force correct leap=00.
Effectively overruling the less sure leap bits of other sources.

David L. Mills

unread,
Dec 29, 2005, 5:54:20 PM12/29/05
to
Serge,

You really should read the commentary in the NIST leapsecond file, which
explains the rationale for when the file is issued, the epoch of
insertion and the current TAI offset. The file does not expire when the
leap is inserted; it remains valid as a record of past TAI offsets until
the next edition is issued.

It could be that some sites have an old edition and others a newer one.
The Autokey protocol compares the leapsecond tables for itself and its
upstream servers and uses only the newest one. If the client has
dependent clients, it passes only the newest table to them.

When multiple valid sources display conflicting leap bits, the logical
OR of these bits is used. While a more sophisticated decision algorthm
could be used, the most common error is when an upstream server does not
implement or recognize the leap condition. Thus if a server sets the
bits, it probably knows what it is doing.

Dave

Richard B. Gilbert

unread,
Dec 29, 2005, 6:58:05 PM12/29/05
to
David L. Mills wrote:

Does ntpd maintain a copy of this leap second file somewhere? Where?

I'd always assumed that NIST servers set the leap second bits when it
was time to set them; that they propagated downward and the leap second
happened automagically, everywhere. Does GPS propagate the leap second
bits?

Marc Brett

unread,
Dec 29, 2005, 9:08:56 PM12/29/05
to
On Thu, 29 Dec 2005 18:58:05 -0500, "Richard B. Gilbert"
<rgilb...@comcast.net> wrote:

> Does GPS propagate the leap second bits?

GPS does better than that -- it broadasts the exact date and time (and
direction) of the next leap second. The firmware of most GPS receivers throw
away that information and simply reduce it to a single trinary bit (+ve leap |
-ve leap | 0 leap). If ever there is a leap second in March or September, there
will be some unnecessary ambiguity because of this.

Serge Bets

unread,
Dec 30, 2005, 2:00:11 AM12/30/05
to
On Thursday, December 29, 2005 at 22:54:20 +0000, David L. Mills wrote:

> You really should read the commentary in the NIST leapsecond file

Thanks for the hint. Latest leap-seconds.3331497600 comments:

| The following entry specifies the expiration date of the data in this
| file in units of seconds since 1900.0. This expiration date will be
| changed at least twice per year whether or not a new leap second is
| announced.

And the important dates in order are:

| Last Update of leap second values: 28 July 2005
| [latest positive leap in table] 1 Jan 2006
| File expires on: 28 June 2006


> The file does not expire when the leap is inserted; it remains valid
> as a record of past TAI offsets until the next edition is issued.

Better than that: An issue remains completely valid until just before
next still uncertain event opportunity.


> When multiple valid sources display conflicting leap bits, the logical
> OR of these bits is used.

Currently one leap=01 source wins the consensus over any number of
leap=00 sources. That's fine, because many sources don't carry leap bits
at all. But that can be fooled, if the leap=01 source is wrong. Seen
here reports of this HP Zsomething, or that Truetime GPS, anouncing leap
or leaping themselves at a wrong date.

The NIST file could win consensus until expiration, making sure no
spurious leap second announcement is done.

Roman Mäder

unread,
Dec 30, 2005, 3:38:50 AM12/30/05
to

> ...

> GPS does better than that -- it broadasts the exact date and time (and
> direction) of the next leap second. The firmware of most GPS receivers
> throw away that information and simply reduce it to a single trinary bit
> (+ve leap | -ve leap | 0 leap).

it seems that the NMEA refclock cannot handle the leap information. It
supports only the $GPRMC or $GPGGA sentences, which do not carry leap
information. It would have to parse the $PGRMF sentence, which seems to
carry this information (as indicated in the Garmin 18 manual)

Roman Maeder

Serge Bets

unread,
Dec 30, 2005, 4:15:00 AM12/30/05
to
Hello Richard,

On Thursday, December 29, 2005 at 18:58:05 -0500, Richard B. Gilbert wrote:

> Does ntpd maintain a copy of this leap second file somewhere? Where?

The operator puts the leapseconds file in the keysdir. The daemon reads
the file, but does not save it, nor update it in any way. The daemon
propagates a volatile in-memory copy of the data table extracted from
the file to its clients using Autokey authentication protocol.


> I'd always assumed that NIST servers set the leap second bits when it
> was time to set them; that they propagated downward and the leap
> second happened automagically, everywhere.

Yes: That's the main scheme. Just note that not everybody is downstream
of NIST, or has a leap bits clean path from NIST. And any other server
can assert leap bits.

The optional NIST leapseconds file is complementary. The data table
gives to the NTP daemon and to its Autokey clients more infos than
simple tristate leap bits: Epoch of next leap second (roughly 5 monthes
in advance), and current TAI offset. And it gives them enough authority
to assert leap=01 during the last 30 days.

Finally clients not using Autokey and not having themselves the NIST
file are informed only by received leap bits.

0 new messages