[ntp:questions] Failed to test leapsecond's handling
brontolinux at gmail.com
Thu Mar 8 14:58:55 UTC 2012
Hi Miroslav, all
It looks like it took more than 15 seconds for this to work correctly...
Il 08/03/2012 14:28, Miroslav Lichvar ha scritto:
> Do you see the leap bit enabled in ntptime or adjtimex output?
I didn't check ntptime or adjtimex before, so I tried now: I re-set the
time to June 30th, 23:55:00 and I see the leap second armed in ntpq's rv:
associd=0 status=4519 leap_add_sec, sync_local, 1 event, leap_armed,
I didn't see the leap second armed immediately with adjtimex (adjtimex
--print | grep status returned 1 for a while), but now after a few
minutes it reports 17 correctly:
root at leapstick:~# adjtimex --print | grep status
while ntptime reports
root at leapstick:~# ntptime
ntp_gettime() returns code 1 (INS)
time d39a1169.5d1d2000 Sat, Jun 30 2012 23:59:37.363, (.363726),
maximum error 458280 us, estimated error 0 us
ntp_adjtime() returns code 1 (INS)
modes 0x0 (),
offset 0.000 us, frequency 97.395 ppm, interval 1 s,
maximum error 458280 us, estimated error 0 us,
status 0x11 (PLL,INS),
time constant 6, precision 1.000 us, tolerance 500 ppm,
At the right time ntpd actually inserted the leap second:
Jun 30 23:59:59 leapstick kernel: [1293608.501308] Clock: inserting leap
second 23:59:60 UTC
And I verified that Squeeze actually steps back the clock :(
2012/06/30 23:59:59.999590790 0.000000008200004
2012/06/30 23:59:59.000300870 -0.000011565854948
2012/06/30 23:59:59.000996706 0.000000008054485
(the second column is the increment relative to the previous line)
For the record, this is uname -a on squeeze:
Linux leapstick 2.6.32-5-amd64 #1 SMP Mon Jan 16 16:22:28 UTC 2012
I don't know if leap seconds are handled better in more recent kernels.
> Is the local timezone UTC?
> It would be interesting to also try "disable kernel" in the
I can do that, if it's still some value. Please let me know.
Thanks for your help.
More information about the questions