Re: [LEAPSECS] Internet-Draft on UTC-SLS

From: Markus Kuhn <Markus.Kuhn_at_CL.CAM.AC.UK>
Date: Thu, 19 Jan 2006 18:30:02 +0000

"M. Warner Losh" wrote on 2006-01-19 16:58 UTC:
> > http://www.ietf.org/internet-drafts/draft-kuhn-leapsecond-00.txt
> The biggest objection that I have to it is that NTP servers will be at
> least .5s off, which is far outside the normal range that NTP likes to
> operate. Unless the prceice interval is defined, you'll wind up with
> the stratum 1 servers putting out different times, which ntpd doesn't
> react well to.

Please read the proposal carefully (Section 2):

   UTC-SLS is not intended to be used as a drop-in replacement in
   specifications that are themselves concerned with the accurate
   synchronization of clocks and that have already an exactly specified
   behavior near UTC leap seconds (e.g., NTP [RFC1305], PTP [IEC1588]).

What this means is:

  - NTP still uses UTC on the wire, exactly in the same way in which it
    does so far, *independent* of whether any of the NTP servers or clients
    involved supply UTC-SLS to their applications.

  - NTP implementations (by this I mean the combined user-space and
    kernel-space segments) should convert NTP timestamps that have been
    received over the wire through the UTC -> UTC-SLS mapping, and steer
    after that what gettimeofday() provides to users .

  - NTP implementations should equally also convert any timestamp received
    from gettimeofday through the UTC-SLS -> UTC mapping before it goes
    out the wire.

In other words, *no* incompatible changes are made to the NTP protocol.
In a correct UTC-SLS implementation, you should *not* be able to
distinguish remotely, whether some NTP server synchronizes its kernel
clock to UTC or UTC-SLS, because this must not influence its NTP
interface in any way.

I hope this answers your concerns.

[Pretty much the same applies not only for NTP, but also for PTP and
other timecodes.]

> I'm also concerned about the fact that many radio time codes do not
> announce the leap second pending until the last hour or less. This
> makes it hard to propigate out to the non-stratum 1 servers.

I fully agree that leap seconds should be announced as early as
possible, and I think that anything less than a month is undesireable.
GPS sends out announcements within days after IERS does, which is
excellent service. NIST sends out announcements a month in advance on
their WW* stations, which is also pretty good. DCF77/HBG sadly do so
only 59 minutes in advance, which is not ideal, but still useful.

However, MSF has no leap warning at all, nor do some time codes used in
the power or military industry. And recent extensions to the latter
added only a leap second warning that arrives a few seconds before the
leap. I consider the leap-second handling of these latter time codes
pretty useless.

> It is a horrible idea.

Since you seem to have arrived at this initial conclusion based on a
misunderstanding of the intended interaction between NTP and UTC-SLS, I
would be interested to hear your view again, after you have appreciated
that UTC-SLS *can* be implemented in NTP software easily and robustly in a
way that is fully backwards compatible with the existing NTP protocol
and infrastructure.

Markus

--
Markus Kuhn, Computer Laboratory, University of Cambridge
http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
Received on Thu Jan 19 2006 - 10:30:40 PST

This archive was generated by hypermail 2.3.0 : Sat Sep 04 2010 - 09:44:55 PDT