In message: <E1EzfyK-0000pR-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 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!
No. You misunderstand me. There were no GPS receivers that did
UTC-SLS-alike timestamps. This was what CLIENTS of the GPS receiver
did. The GPS receiver did exactly the right thing, ntp did the right
thing, our products did the right thing. What I observed was in the
CLIENTS how they dealt with the leap seconds.
GPS-RECEIVER --- GPSNTPD --- NTP CLIENT1[*] windows NT box
+-- NTP CLIENT2[*] Linux box
+-- NTP CLIENT3[*] FreeBSD box
+-- NTP CLIENT4[*] FreeBSD box
The items marked with a [*] are the ones I observed. client1 and
client2 were the ones that I observed implementing UTC-SLS like time
and such time was visible to the outside world. I was clearly able to
see both on the GPSNTPD clients 3 and 4 the skews of clients 1 and 2
during the leap second, where I observed no such skews relative to
GSPNTPD.
I'm saying that certain OSes have implemented the UTC-SLS-like
systems. I'm saying that ntp daemons running on those systems use the
actual system time for time exchanges, rather than real UTC. I'm
saying that this can cause confusion to a downstream ntp client and
that's my basis for thinking this idea is not good. I'm further
saying that for the OS to support ntpd, it would need to also support
UTC and provide an interface to get the raw UTC time. It would need
to keep track of steers for the purpose of implementing UTC-SLS and
steers needed to compensate for the changing base clock frequency
separate so that it could give the right time when asked for UTC
time. It would also need to give some kind of feedback to ntpd that
it didn't do the small steer it wanted because UTC-SLS is going on at
that time (since otherwise ntp would think that there's some frequency
step going on if it just ignored it, and doing both steers
concurrently would be very hairy).
It is a seductive idea that leaves one with a big hangover in the
morning.
: > : 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
Excuse me, but isn't it a bit patronizing to point someone at a
beginner's guide? I don't need beginner's overviews. I have plenty.
I've been dealing with Irig for several years now, as well as many
other time codes and timing issues (including leap seconds). What I
need is references to standards and copies of standards. I want to
understand all the variations of IRIG so I know what the
sales/marketing folk are talking about when they ask me if thus and
such standard is easy or hard.
: 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.
http://standards.ieee.org/reading/ieee/std_public/description/relaying/1344-1995_desc.html
would have been a good citation for that standard (although I'm not an
IEEE member, I can't download it). There are many other layered
standards on top of the IRIG 200-04 standard as well, as you indicate.
I'm trying to collect them, since usually they are filtered down to me
as photocopies of pictures that don't really have all the data that's
needed :-(.
Warner
Received on Thu Jan 19 2006 - 13:10:47 PST