"M. Warner Losh" wrote on 2006-01-19 19:20 UTC:
> : 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.
Yes, of course! If you connect a GPS receiver that delivers an
undocumented UTC-SLS-alike timescale on its output to an NTP server that
in turn knows nothing of this UTC-SLS-alike timescale and is not
implemented accordingly, you must get a mess. What did you expect? What
you observed is *not* an implementation of UTC-SLS, but just a
connection of incompatible components!
If people, like the manufacturer of said GPS receiver, want to work with
smoothed leap seconds, then it would surely help if these smoothed leap
seconds were standardized and properly documented in easily quoteable
archival form, with an unabiguous name that every time-keeping expert
understands. That is what I want to achieve with this RFC draft. The
result (in your particular scenario) should then be
a) GPS receivers that have a UTC-23:59:60 versus UTC-SLS switch in
their firmware
b) an xntpd driver for that receiver that has the same switch in its
input configuration options
c) lots of installations, where both switches are set the same way
(Even better, of course, would be strictly standardized protocols
between GPS receivers and NTP server that make such switches
unnecessary!)
NTP servers can easily convert between UTC and UTC-SLS, because the know
when the next leap second is, and the can therefore use the simple
conversion formula from section 5 of the spec in either direction. It is
just 1 comparison, one addition, one multiplication and one subtraction.
Nothing more complicated then the arithmetic you have to do anyway if
you convert a high-resolution hardware counter into a standard
timescale.
> 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...
So simply use GPS receivers and NTP servers that agree on what they do
use on the wire.
> : 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...
The IRIG world is clearly a huge mess, with more than two dozen
formats in use. A useful beginner's overview is at
http://www.symmttm.com/pdf/Gps/an_Time_and_Time_Code_Ref.pdf
which outlines on page 23 the 27-bit IEEE 1355 power-industry extension
to IRG-B that has a Leap Second Pending (LSP) bit that "becomes 1 up to
59 sec before leap second insertion". That was the one I referred to. If
you have a good and very reliable signal, it may be just good enough to
insert 23:59:60 in time, but it is useless for anything really robust.
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 - 12:01:41 PST