"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