[ntp:questions] Leap second bug?

David L. Mills mills at udel.edu
Fri Jan 4 15:30:01 UTC 2008


Spoon,

Assuming your incident was the beginnin of this year, no leap was 
schedule nor should have been advertisec by any of your servers. The 
current code, which you might not be using, takes a vote of the leap 
indicators in all servers and requires a clear majority before 
scheduling a leap. Maybe some of your friends lied.

The intended behavior if the servers do correctly signal a leap and the 
kernel is unaware of that, is that the step interval will be exceeded 
for about 15 minutes and then the time will be stepped. During that 
interval your clock will appear one second slow relative to the server 
that has correctly inserted a second. There will be no slew, onlly the 
step. The fact that your time showed otherwise suggests either the step 
has been disabled or something else comes unstuck. Our clocks here 
showed no such behavior as yours.

Dave

Spoon wrote:

> Spoon wrote:
> 
>> ntpd kicked my clock forward one second on January 1 at 00:19:38 UTC.
>>
>> (My ntp.conf lists 12 servers. Delays range from 28 to 48 ms.)
>>
>> Dec 31 23:25:39 offset 0.000329 sec freq -6.715 ppm error 0.000333 poll 8
>> Dec 31 23:28:39 offset 0.000329 sec freq -6.715 ppm error 0.000340 poll 8
>> Dec 31 23:31:39 offset 0.000329 sec freq -6.715 ppm error 0.000424 poll 8
>> Dec 31 23:34:39 offset 0.000403 sec freq -6.714 ppm error 0.000493 poll 8
>> Dec 31 23:37:39 offset 0.000270 sec freq -6.714 ppm error 0.000348 poll 8
>> Dec 31 23:40:39 offset 0.000270 sec freq -6.714 ppm error 0.000337 poll 8
>> Dec 31 23:43:39 offset 0.000268 sec freq -6.714 ppm error 0.000327 poll 8
>> Dec 31 23:46:39 offset 0.000268 sec freq -6.714 ppm error 0.000381 poll 8
>> Dec 31 23:49:39 offset 0.000268 sec freq -6.714 ppm error 0.000446 poll 8
>> Dec 31 23:52:39 offset 0.000268 sec freq -6.714 ppm error 0.000446 poll 8
>> Dec 31 23:55:39 offset 0.000268 sec freq -6.714 ppm error 0.000334 poll 8
>> Dec 31 23:58:39 offset 0.000268 sec freq -6.714 ppm error 0.000317 poll 8
>> Jan  1 00:01:38 offset 0.000268 sec freq -6.714 ppm error 0.000318 poll 8
>> Jan  1 00:04:38 offset 0.000268 sec freq -6.714 ppm error 0.447285 poll 8
>> Jan  1 00:06:47 synchronized to A, stratum 2
>> Jan  1 00:07:38 offset -0.001068 sec freq -6.720 ppm error 0.632509 
>> poll 8
>> Jan  1 00:10:38 offset -0.001068 sec freq -6.720 ppm error 0.632509 
>> poll 8
>> Jan  1 00:13:38 offset -0.001068 sec freq -6.720 ppm error 0.774695 
>> poll 8
>> Jan  1 00:15:39 synchronized to H, stratum 1
>> Jan  1 00:16:38 offset -0.001068 sec freq -6.720 ppm error 0.632382 
>> poll 8
>> +++++
>> Jan  1 00:19:38 time reset +0.999402 s
>> +++++
>> Jan  1 00:19:38 system event 'event_clock_reset' (0x05) status 
>> 'sync_alarm, sync_unspec, 15 events, event_peer/strat_chg' (0xc0f4)
>> Jan  1 00:19:38 system event 'event_peer/strat_chg' (0x04) status 
>> 'sync_alarm, sync_unspec, 15 events, event_clock_reset' (0xc0f5)
>> Jan  1 00:19:39 offset 0.000000 sec freq -6.720 ppm error 0.447203 poll 4
>> Jan  1 00:19:54 peer A event 'event_reach' (0x84) status 'unreach, 
>> conf, 2 events, event_reach' (0x8024)
>> Jan  1 00:19:55 peer B event 'event_reach' (0x84) status 'unreach, 
>> conf, 2 events, event_reach' (0x8024)
>> Jan  1 00:19:59 peer C event 'event_reach' (0x84) status 'unreach, 
>> conf, 2 events, event_reach' (0x8024)
>> Jan  1 00:20:04 peer D event 'event_reach' (0x84) status 'unreach, 
>> conf, 2 events, event_reach' (0x8024)
>> Jan  1 00:20:07 peer E event 'event_reach' (0x84) status 'unreach, 
>> conf, 2 events, event_reach' (0x8024)
>> Jan  1 00:20:08 peer F event 'event_reach' (0x84) status 'unreach, 
>> conf, 4 events, event_reach' (0x8044)
>> Jan  1 00:20:14 peer G event 'event_reach' (0x84) status 'unreach, 
>> conf, 2 events, event_reach' (0x8024)
>> Jan  1 00:20:18 peer H event 'event_reach' (0x84) status 'unreach, 
>> conf, 2 events, event_reach' (0x8024)
>> Jan  1 00:20:24 peer I event 'event_reach' (0x84) status 'unreach, 
>> conf, 2 events, event_reach' (0x8024)
>> Jan  1 00:20:26 peer J event 'event_reach' (0x84) status 'unreach, 
>> conf, 2 events, event_reach' (0x8024)
>> Jan  1 00:20:28 peer K event 'event_reach' (0x84) status 'unreach, 
>> conf, 2 events, event_reach' (0x8024)
>> Jan  1 00:20:39 peer L event 'event_reach' (0x84) status 'unreach, 
>> conf, 4 events, event_reach' (0x8044)
>> Jan  1 00:20:55 synchronized to A, stratum 2
>> Jan  1 00:20:55 system event 'event_sync_chg' (0x03) status 
>> 'leap_none, sync_ntp, 15 events, event_peer/strat_chg' (0x6f4)
>> Jan  1 00:20:55 system event 'event_peer/strat_chg' (0x04) status 
>> 'leap_none, sync_ntp, 15 events, event_sync_chg' (0x6f3)
>> Jan  1 00:21:22 synchronized to H, stratum 1
>>
>> I also noticed that, the day before, the STA_INS (insert leap second) had
>> been set and reset several times.
>>
>> Dec 31 00:14:30 kernel time sync status change 0011
>> Dec 31 00:27:21 kernel time sync status change 0001
>> Dec 31 03:19:46 kernel time sync status change 0011
>> Dec 31 03:52:30 kernel time sync status change 0001
>> Dec 31 04:09:33 kernel time sync status change 0011
>> Dec 31 04:35:11 kernel time sync status change 0001
>> Dec 31 07:26:03 kernel time sync status change 0011
>> Dec 31 07:47:28 kernel time sync status change 0001
>> Dec 31 10:00:51 kernel time sync status change 0011
>> Dec 31 10:17:01 kernel time sync status change 0001
>>
>> (Apparently, the bit was not set when 2007 ended.)
>>
>> Could this be a leap year bug? or did I just lose connectivity at the 
>> wrong
>> time and it's just a coincidence?
>>
>> # ntpq -crv
>> assID=0 status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg,
>> version="ntpd 4.2.4p0 at 1.1472 Fri Mar 16 10:45:43 UTC 2007 (1)",
>> processor="i686", system="Linux/2.6.22.1-rt9", leap=00, stratum=3,
>> precision=-20, rootdelay=30.293, rootdispersion=50.341, peer=39672,
>> refid=145.238.203.10,
>> reftime=cb262893.e5d244fd  Wed, Jan  2 2008 15:13:23.897, poll=8,
>> clock=cb262c3b.dbe5d3de  Wed, Jan  2 2008 15:28:59.858, state=4,
>> offset=0.081, frequency=-6.758, jitter=0.525, noise=0.521,
>> stability=0.001
> 
> 
> Would someone care to venture their best guess as to what caused ntpd
> to step the system clock forward in the above scenario?
> 
> Regards.




More information about the questions mailing list