In message: <E1EzeXq-0007mx-00_at_mta1.cl.cam.ac.uk>
Markus Kuhn <Markus.Kuhn_at_CL.CAM.AC.UK> writes:
: "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]).
I saw that, but it does present some interesting implementation issues
for an ntp server.
: 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.
This is the hard part. Right now, NTP steers the system time to UTC
as best it can. It steps the time back by one second at the leap
second since there's no way in POSIX's time_t to represent leap
seconds, and all the time interfaces to the kernel are in terms of
time_t.
During the recent leap second, I observed three different clients of
one of our GPS receivers do three different things with the leap
second: One inserted it early with the kind of hard frequency steer
that UTC-SLS does. The second did it centered around the leap second,
and one didn't do anything until after the leap second and a couple of
polling intervals, then steered it out. It is based on these systems
that implement the UTC-SLS-like steers that I based my reaction on.
: - 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.
This is the difficult part. Right now, ntp daemons use the system
time as the time they do the time exchange with. This is even if they
have a fancy gps receiver connected to them that isn't yet fully
synchronized. Since they use system time, as you observe there would
need to be some mapping. This mapping would necessarily have to be in
the kernel (since only it has the knowledge of the actual UTC UTC-SLS
offset) and would need to be an additional system call. Such system
calls are not yet standardized. This adds additional overhead to the
time exchange, which increases the opportunity for latency to creap
in.
Effectively, you'd have to have two time scales in the kernel. UTC
and UTC-SLS. You make it sound simple, but the hair in doing this may
be quite difficult. There's more book for the kernel to keep, and it
would have to expose the bookkeeping to userland for ntp to work.
What makes this hard is that ntpd may introduce steers into the normal
system time at normal times which it doesn't want to confuse with the
steers in frequency that are used during a UTC-SLS operation.
: 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.
In the systems that I observed over the leap second, I can say that
those systems that did implement a UTC-SLS-like approach to steering
out the extra second were definitely observable while they did this.
Given the variance in approach to this steering, and given it was
observable to the outside world, I concluded that N independent ntp
servers doing this would only confuse ntp clients...
: I hope this answers your concerns.
Well, it raises a whole different set of issues than I had originally
feared. ntpd's use of system time to do its time exchanges has caused
me a significant amount of trouble in the past.
: > 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.
Anything less than 10 years is too late, imho :-)
: 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.
IRIG-B (all IRIG?) has no leap second announcement that I could find.
The Irig standard I could find (IRIG STANDARD 200-04, issued September
2004, at
http://www.jcte.jcs.mil/RCC/PUBS/pubs.htm) makes no mention
of the format of the leap seconds at all (the leap second convention
appendix says that leap seconds happen). Talking to engineers here
who have implemented IRIG at various places reveals that there are
multiple conventions for dealing with leap seconds in irig (the new
standard being to do 59, 60, the old standard was to do 59 59).
There's no provision for leap second announcement, although control
bits do remain unassigned...
If there's a newer standard for irig or some supplamental document
that describes leap seconds, I'd love to know about it.
: > 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.
It would be hariy to implement it. Given enough code, one can
implement just about anything :-).
Warner
Received on Thu Jan 19 2006 - 11:22:51 PST