[ntp:questions] Re: leap second in isolated LAN with LOCAL()

Serge Bets serge.bets at NOSPAM.laposte.invalid
Sun Dec 4 14:14:14 UTC 2005


Hello Michael,

 On Thursday, August 4, 2005 at 21:56:30 -0700, Michael Wouters wrote:

> you can't use ntpdc/xntpdc to set the leap second bits anymore. But
> you can do it manually yourself using the adjtimex() system call on
> Linux. A small C program will do the job ... You can only set the bits
> on the day of the leap second.

Or using the command "adjtimex --status 17" to add 16 to the previous
clock status value seen with --print (was 1 here in my example). It
worked very well in a simulation of next 31 December, thank you.


> once you've set the leap second bits, you can't turn them off.

Well I could turn leap indicator off with "adjtimex --status 1" before
end of the UTC day. Then at next LOCAL(0) poll the daemon noticed it,
came back to leap_none and leap=00, and clients soon followed. And at
midnight nobody leaped.


Now there is an alternative method to cleanly make leap an isolated LAN
with only LOCAL() reference: Using the NIST leap-seconds file. Download
leap-seconds.3331497600 (or latest) file from ftp://time.nist.gov/pub/,
move it to Server's keysdir, make a symlink ntpkey_leap to it, and
restart Server. From the beginning of December, the Server will announce
leap_add_sec and leap=01, but not yet set kernel clock leap bits.
Ntpd 4.2 clients follow Server, and w32time clients also follow. Old
xntpd 3.5 clients do not yet follow, probably waiting for the last day.
On the last day kernel bits will be set, and at midnight the full LAN
will leap. Good!

Note that for some reason I could not understand, leap-seconds file
seems not to be read if you haven't set a crypto password (or rather any
crypto statement), which in turn requires a host certificate and key, as
if you were using autokey. If you don't have them, do on Server:

| # cd /etc/ntp/keysdir
| # ntp-keygen -T -p serverpassword

Content of /etc/ntp/keysdir:

| -rw-r--r-- 8668 jui 28 02:00 leap-seconds.3331497600
| -rw-r--r--  677 nov 11 13:52 ntpkey_RSA-MD5cert_Server.3340702253
| -rw-r--r--  617 nov 11 13:52 ntpkey_RSAkey_Server.3340702253
| lrwxrwxrwx   36 nov 11 13:52 ntpkey_cert_Server -> ntpkey_RSA-MD5cert_Server.3340702253
| lrwxrwxrwx   31 nov 11 13:52 ntpkey_host_Server -> ntpkey_RSAkey_Server.3340702253
| lrwxrwxrwx   23 nov  2 17:54 ntpkey_leap -> leap-seconds.3331497600

And in ntp.conf:

| keysdir /etc/ntp/keysdir
| crypto pw serverpassword

Note that for this leaping method, you don't need to make use of
autokey. And not even need to have a LOCAL() reference. It works well
with refclocks not announcing leap seconds, like radioclkd 1.0 or MSF
receivers. It also cooperates well with refclocks that will announce
leap later, as DCF77 receivers (during the last hour). It should work on
all platforms (but current Win32 binary 4.2.0b at 20051016-1.1417-o does
buggy calculations). There is nothing to do manually on leap day. But
check NIST for an updated file once every 6 monthes.

There is one problem: leap-seconds leaping does not cooperate well with
the new orphan mode. There are inconsistencies, at startup, during
transitions from synced to orphan mode, and when the orphans group
population is 1 only. The Server then announces leap_none leap=00. And
an orphan at startup announces leapsec=200507280000 but tai=0, possibly
forever, or until first sync to anything (other orphan, LOCAL(0), or
another source).


Serge.
-- 
Serge point Bets arobase laposte point net




More information about the questions mailing list