"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