text book example why Leapseconds are bad
http://lheawww.gsfc.nasa.gov/users/ebisawa/ASCAATTITUDE/ -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: went pretty dang smoothly at this end
On Sat, 31 Dec 2005, Steve Allen wrote: On Sat 2005-12-31T20:51:03 -0500, Keith Winstein hath writ: (b) Am I mistaken, or did WWV fail to correctly beep in the new year? We had two shortwave radios going, one on 10 MHz, one on 15 MHz, and with the two the ionosphere was pretty much tamed. To my memory they did it all right, including the change in the DUT1 clicks, but I can check later. Looks like you were right. John Ackermann on time-nuts has posted some recordings at http://www.febo.com/time-freq/leapsecond-2005/, and the 1.5 kHz tone is there. Guess we were mistaken after all. -Keith
Re: went pretty dang smoothly at this end
On Sat, 31 Dec 2005, Rob Seaman wrote: Was watching time.gov and leapsecond.com (the comparative clocks). Counted up to 23:59:60 (well, 16:59:60 in Tucson). The GPS-UTC incremented as did the TAI-UTC. The TV didn't melt down either. No obvious Airbuses plummeting from the sky. Life be good. I was on board a United Airlines Boeing 777 en route from Chicago to London. We were at 30,000 feet somewhere over eastern Canada when the leap second occurred. The first officer gave us a countdown to midnight in London, and I'm happy to report that the plane failed to fall out of the sky, explode, or otherwise deviate from its course at 23:59:60. David Harper
Re: went pretty dang smoothly at this end
Keith Winstein wrote: Some minor glitches: (a) My Garmin 12XL GPS receiver (software version 4.53) did not register the leap second on its time display. It went from 58 to 59 to 00, and stayed one second ahead for the next few minutes until I rebooted it. Then it came up correctly. Interesting. My 12XL (software version 4.60) dealt with the leap second pretty well, I thought. It seemed to hold at 23:59:59 for two seconds. More details: http://www.edavies.nildram.co.uk/gps12xl-leapsecond/ Ed.
Re: December 2005 leap second on MSF, Rugby, England
On Sun, 1 Jan 2006, David Malone wrote: I didn't have the facilities to record any phase information. I did try recording BBC Radio 4, but they transmitted Big Ben rather than pips ;-( Having found that problem with Radio 4 last leap second, I tried BBC World Service this time (having tested the night before that they broadcast the pips at midnight) but they also broadcast Big Ben for the New Year. Where does broadcast the pips at the New Year? The Linux kernel (with NTP synchronisation) duly syslogged Dec 31 23:59:59 digraph kernel: Clock: inserting leap second 23:59:60 UTC and Markus's program showed a transition from 1136073600.005623 to 1136073599.013130, i.e. 23:59:59 was repeated (whereas a POSIX clock in perfect synchronisation with UTC should appear to repeat 00:00:00, and a kernel source code comment /* The timer interpolator will make time change gradually instead * of an immediate jump by one second. */ describes what would practically be a safer approach, if the code followed the comment). I tried polling the plain text (not Java) clock on www.time.gov (via lynx -dump http://www.time.gov/timezone.cgi?UTC/s/0 | head -5), but around the time of the leap second that seemed heavily overloaded and taking much longer than a second to return results. However I alternated the results from that clock with local clock timestamps (which as above had had the leap second inserted by repeating 23:59:59), and a result from www.time.gov of Right now, the official U.S. time is: 00:00:05 Sunday, January 1, 2006 was immediately followed by a local timestamp of Sun Jan 1 00:00:04 UTC 2006, suggesting that the www.time.gov text clock had not inserted the leap second at that point (or it has rounded the time to the next rather than the previous second boundary). I didn't think to log the HTTP header timestamps as well as the timestamp in the page text. -- Joseph S. Myers [EMAIL PROTECTED]
Re: December 2005 leap second on MSF, Rugby, England
In message: [EMAIL PROTECTED] Joseph S. Myers [EMAIL PROTECTED] writes: : The Linux kernel (with NTP synchronisation) duly syslogged : : Dec 31 23:59:59 digraph kernel: Clock: inserting leap second 23:59:60 UTC : : and Markus's program showed a transition from 1136073600.005623 to : 1136073599.013130, i.e. 23:59:59 was repeated (whereas a POSIX clock in : perfect synchronisation with UTC should appear to repeat 00:00:00, and a : kernel source code comment : : /* The timer interpolator will make time change gradually instead : * of an immediate jump by one second. : */ : : describes what would practically be a safer approach, if the code followed : the comment). ntp synced computers repeat the last second of the day. POSIX is just flat wrong here. Actually, POSIX is completely silent on what is to happen at the leap second to system time. Once can infer what might be the right behavior by working backwards from what mktime does for 23:59:60, but that's a weak inference for what the 'right' posix behavior is for the system time accross a leap second. POSIX simply does not have leap seconds in any meaningful way. It is as if they do not exist at all. There's no clarifications to the POSIX standard that say that 0:00:00 should be repeated at a leap second, at least that I've been able to find. If there is such an explicit clarification, I'd like to know about it. FreeBSD does the same thing (as do all kernels that use the ntp kernel stuff supplied with udel ntpd and successors). FreeBSD doesn't actually log the leap second via syslog, but maybe it should. Ideally, we'd switch to running computers with TAI and doing all the conversion on input/output of time. However, *THAT*'s definitely not POSIX. Warner
Leap Second in GPS Receiver NMEA Log
Here are the logged NMEA $GPZDA messages from a ublox Antaris SuperSense GPS receiver: $GPZDA,235955.00,31,12,2005,00,00*6D $GPZDA,235956.00,31,12,2005,00,00*6E $GPZDA,235957.00,31,12,2005,00,00*6F $GPZDA,235958.00,31,12,2005,00,00*60 $GPZDA,235959.00,31,12,2005,00,00*61 $GPZDA,235960.00,31,12,2005,00,00*6B $GPZDA,00.00,01,01,2006,00,00*62 $GPZDA,01.00,01,01,2006,00,00*63 $GPZDA,02.00,01,01,2006,00,00*60 $GPZDA,03.00,01,01,2006,00,00*61 $GPZDA,04.00,01,01,2006,00,00*66 $GPZDA,05.00,01,01,2006,00,00*67 -- Richard Langley === Richard B. LangleyE-mail: [EMAIL PROTECTED] Geodetic Research Laboratory Web: http://www.unb.ca/GGE/ Dept. of Geodesy and Geomatics EngineeringPhone:+1 506 453-5142 University of New Brunswick Fax: +1 506 453-4943 Fredericton, N.B., Canada E3B 5A3 Fredericton? Where's that? See: http://www.city.fredericton.nb.ca/ ===
CDMA glitches, and TAI over NTP
There is an interesting thread at http://groups.google.com/group/comp.protocols.time.ntp/browse_thread/thread/30a0f68a30f83f1e/ in which Bruce Penrod notes that some of their customers didn't configuree their CDMA cell phone basestations right: We are pleased to announce that our GPS NTP servers and our CDMA NTP servers configured in user leap mode performed the leap properly this afternoon. We are aware that some of the cellular basestations set the leap second a day early, and some PCS basestations have still not set it. We regret that some customers apparently had not configured their NTP servers to operate in user leap second mode, and apologize for any problems this might have caused. David L. Mills writes: There is an obvious remedy here. If your unit implements Autokey, and it does implement just about everything else, it could run in TAI and deliver the UTC offsets in an extension field. I would be happy to collaborate on an RFC to that effect. I also note this at http://www.eecis.udel.edu/~mills/ntp.html: Recently, the precision time kernel support now incorporated in the kernels for Tru64, Solaris, Linux and FreeBSD has been updated to improve accuracy and resolution to the nanosecond. In addition, a plan has been worked out with NIST for the distribution of International Atomic Time (TAI) via NTP using the Autokey protocol. I'd love to see TAI over NTP, and am glad to see some motion in that direction. Anyone know more? Cheers, Neal McBurnett http://bcn.boulder.co.us/~neal/
TAI, NTP and IETF; IEEE 1588
I hadn't run across NIST's leap seconds table before: ftp://time.nist.gov/pub/leap-seconds.list I'm finally beginning to catch up on NTP developments over the last several years, and find that current xntpd code can use that table, and transport leap second tables around using an autokey feature: http://groups.google.com/group/comp.protocols.time.ntp/browse_thread/thread/db2f5f47aab68a3d/ There is an IETF NTP working group now: http://ietf.org/html.charters/ntp-charter.html There was some discussion of leap seconds at the NTP working group session of the Internet Engineering Task Force (IETF) meeting in Vancouver in September: http://www3.ietf.org/proceedings/05nov/ntp.html It is unclear whether the current autokey security mechanism will end up in an IETF standard, since it is rather different from other standard internet security mechanisms. That meeting also mentions IEEE 1588-2002 Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems. See http://ieee1588.nist.gov/ It seems that IEEE 1588 time bases are continuous from a defined epoch, but I don't know much more about that. There was also a note in the IETF meeting of possible leap second issues in the RTP protocol. There was later discussion on the NTP working group mail list about sending in comments to the ITU. Here is Steve Allen's comment, cogent as always, and links to the rest: http://lists.ntp.isc.org/pipermail/ntpwg/2005-October/000165.html I don't know if they ever sent in comments to ITU. Neal McBurnett http://bcn.boulder.co.us/~neal/ Signed and/or sealed mail encouraged. GPG/PGP Keyid: 2C9EBA60
Re: went pretty dang smoothly at this end
The first officer gave us a countdown to midnight in London, and I'm happy to report that the plane failed to fall out of the sky, explode, or otherwise deviate from its course at 23:59:60. Did his countdown reach zero at 23:59:60 31-December-2005 UTC or at 00:00:00 1-January-2006 UTC ? -Tim Shepard [EMAIL PROTECTED]
NTP behavior in Australia
Here is one indication of NTP response to the presence of low stratum servers which did not behave well. http://members.iinet.net.au/~nathanael/ntpd/leap-second.html -- Steve Allen [EMAIL PROTECTED]WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165Lat +36.99858 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06014 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m
