Hello everybody, and best wishes to you all. Here are some commented
logs and my quick notes about *The Leap*:
Leap second insertion on Saturday 31 December 2005 at 23:59:60 UTC.
Local time of event is Sunday 1 January 2006 at 00:59:60 CET +0100.
DCF77 receiver: Jonathan A. Buzzard's Conrad 641138 simple DIY clock.
Recorder: Jon Atkins' radioclkd2 0.06 slightly modified.
Recorded DCF77 pulses: "." == 0, "1" == 1, "x" == no pulse.
TZL mmmmMMM hhhhHH ddddDDjjjmmmmMyyyyYYYY
|0 |5 |10 |15 |20 |25 |30 |35 |40 |45 |50 |55 |60
..................111...11.11.......1.....1111.....11.....1x 2006-01-01 (day
7) 00:58 CET leap second soon main ant
..................1111..11.1........1.....1111.....11.....1x 2006-01-01 (day
7) 00:59 CET leap second soon main ant
..................111........1.....11.....1111.....11.....1.x 2006-01-01 (day
7) 01:00 CET leap second soon main ant
..................1.11......11.....11.....1111.....11.....1x 2006-01-01 (day
7) 01:01 CET main ant
..................1.1.1.....11.....11.....1111.....11.....1x 2006-01-01 (day
7) 01:02 CET main ant
|0 |5 |10 |15 |20 |25 |30 |35 |40 |45 |50 |55 |60
data(60):
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,2,2,2,1,1,1,2,2,1,2,2,1,1,1,1,1,1,1,2,1,1,1,1,1,2,2,2,2,1,1,1,1,1,2,2,1,1,1,1,1,2,0,
data(60):
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,2,2,2,2,1,1,2,2,1,2,1,1,1,1,1,1,1,1,2,1,1,1,1,1,2,2,2,2,1,1,1,1,1,2,2,1,1,1,1,1,2,0,
data(61):
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,2,2,2,1,1,1,1,1,1,1,1,2,1,1,1,1,1,2,2,1,1,1,1,1,2,2,2,2,1,1,1,1,1,2,2,1,1,1,1,1,2,1,0,
data(60):
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,2,1,2,2,1,1,1,1,1,1,2,2,1,1,1,1,1,2,2,1,1,1,1,1,2,2,2,2,1,1,1,1,1,2,2,1,1,1,1,1,2,0,
data(60):
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,2,1,2,1,2,1,1,1,1,1,2,2,1,1,1,1,1,2,2,1,1,1,1,1,2,2,2,2,1,1,1,1,1,2,2,1,1,1,1,1,2,0,
Note that both radioclk-1.0 and radioclkd2 0.06 original radioclock
drivers failed to decode the 01:00 minute: They did not detect the
minute marker, fooled by a non-monotonic gettimeofday() repeating the
second 59. Example radioclkd2 0.06: Instead of decoding one 61 seconds
minute 01:00, followed by one 60 seconds minute 01:01, it decoded one
120 seconds minute 01:01. Raw data:
data(120):
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,2,2,2,1,1,1,1,1,1,1,1,2,1,1,1,1,1,2,2,1,1,1,1,1,2,2,2,2,1,1,1,1,1,2,2,1,1,1,1,1,2,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,2,1,2,2,1,1,1,1,1,1,2,2,1,1,1,1,1,2,2,1,1,1,1,1,2,2,2,2,1,1,1,1,1,2,2,1,1,1,1,1,2,0,
In clear: The minute marker sequence "0,1" was wrongly timed as one "1".
Raw gettimeofday() timings (not corrected by time1 0.020 offset):
pulse start: at 1136073598.019534
pulse end: length 0.191548 - 58: 2
pulse start: at 1136073599.021453 (that's the 1st second 59)
pulse end: length 0.091303 - 59: 1
pulse start: at 1136073600.018443 (that's the only second 0)
pulse end: length 0.096868 - 60: 1
pulse start: at 1136073601.018891
pulse end: length 0.095290 - 61: 1
Main stratum 1 Linux Debian Woody recent ntp-dev 4.2.0b server. DCF
refclock SHM(0) interfaced with Jonathan A. Buzzard's radioclkd 1.0
patched to deal with leap seconds. It leaped gracefully. Just that
instead of inserting a second 60, it repeated twice the second 59.
Sequence of events began in early December, when the server informed by
the NIST leapseconds file started to announce leap=01 30 days in
advance.
Then it has set kernel leap bits (0x11 ==> PLL+INS) 1 day in advance.
Then DCF77 radio announced the leap 1 hour in advance.
And the kernel leaped.
Dec 31 01:00:45 kassad ntpd[13775]: kernel time sync enabled 0011
Jan 1 00:01:00 kassad radioclkd[259]: DCF77 on DCD line announces leap second
insertion
Jan 1 00:59:59 kassad kernel: Clock: inserting leap second 23:59:60 UTC
Jan 1 01:01:00 kassad radioclkd[259]: DCF77 on DCD line stops announcing leap
second
Later DCF77 shut off bit 19.
The NTP daemon announced leap=00 and tai=33.
All was well, frequency and phase.
Success: Congratulations, professor Mills! Much thanks to you, and to
all the team that made this possible. :-)
I also had a bunch of various stratum 2 clients.
- Woody ntp-dev 4.2.0b 20051225 leaped gracefully.
- Old Linux xntpd 3-5.93e leaped gracefully. Only difference is it took
the leap=01 only on the last day, as per NTPv3 specification.
Dec 31 01:00:23 biben xntpd[130]: system event 'event_sync_chg' (0x03) status
'leap_add_sec, sync_ntp, 7 events, event_peer/strat_chg' (0x4674)
Jan 1 00:59:59 biben kernel: Clock: inserting leap second 23:59:60 UTC
Jan 1 01:00:19 biben xntpd[130]: system event 'event_sync_chg' (0x03) status
'leap_none, sync_ntp, 15 events, event_peer/strat_chg' (0x6f4)
- Windows 98SE running Tardis 2000. Never took leap bits, and whether
it leaped or not is unsure. I failed the logging.
- Windows 2000 running w32time. Took the leap=01 one month in advance,
and was since then repeatedly polling the server each day some seconds
around midnight UTC. Previous midnights it didn't leap, this one it
leaped gracefully.
- 2 autonomous DCF clocks did not leap. But they resynced to the radio
during the following couple of minutes. Normal hourly resync.
- Windows 2000 running [EMAIL PROTECTED] was
apparently behaving well. Announcing leap=01 long in advance, the
service doing itself the leap...
Dec 22 22:12:59 oniko NTP: N/A: Detected positive leap second announcement for
2006-01-01 00:00:00 UTC
Jan 1 01:00:03 oniko NTP: N/A: Inserting positive leap second.
But all went wrong after the leap. The service entered a cycle of
wildly bad frequency, like +50 or -120 instead of -20.8 PPM, with offset
quickly wandering, then time reset. Wander, reset -150 ms. And so on for
hours, without any sign of stabilisation. 20 hours later it is still
totally broken. I give up: Deleted drift file and restarted.
Serge.
--
Serge point Bets arobase laposte point net
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
