Re: [ntp:questions] Failed to test leapsecond's handling
On Thu, Mar 08, 2012 at 01:10:02PM +0100, Marco Marongiu wrote: > But when I graph the time log (see the log target in the makefile), I > don't see the leap second kicking in. Based on Mills' "The NTP Timescale > and Leap Seconds"[1], when the leap second kicks in, I'd expect two > consecutive date command to _appear_ happen at different offset than in > normal conditions. Unfortunately, that didn't happen, and if I draw a > line of the accumulated offsets between consecutive runs of the command, > the line is almost perfectly straight. Do you see the leap bit enabled in ntptime or adjtimex output? Is the local timezone UTC? Just to make sure the date commands sets time to before 0:00 UTC and not some other hour. It would be interesting to also try "disable kernel" in the ntp.conf. In a clknetsim simulation with ntp-4.2.6p5 I can see the clock is correctly stepped by 1.0 second. Here is the ntpd log (in UTC+2 timezone): http://pastebin.com/ZRi6qv8E -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Failed to test leapsecond's handling
On Thu, Mar 08, 2012 at 02:28:07PM +0100, Miroslav Lichvar wrote: > In a clknetsim simulation with ntp-4.2.6p5 I can see the clock is > correctly stepped by 1.0 second. Here is the ntpd log (in UTC+2 > timezone): > > http://pastebin.com/ZRi6qv8E In another simulation set to start 15 seconds before midnight it didn't work and it seems ntpd needs to be started sooner, perhaps some number of polling intervals? -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Failed to test leapsecond's handling
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@leapstick:~# adjtimex --print | grep status status: 17 while ntptime reports root@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.824 2012/06/30 23:59:59.000300870 -0.11565854948 2012/06/30 23:59:59.000996706 0.8054485 (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 x86_64 GNU/Linux I don't know if leap seconds are handled better in more recent kernels. > Is the local timezone UTC? It is. > It would be interesting to also try "disable kernel" in the > ntp.conf. I can do that, if it's still some value. Please let me know. Thanks for your help. -- bronto ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Failed to test leapsecond's handling
Hi Marco, Marco Marongiu wrote: > Hi Miroslav, all > > It looks like it took more than 15 seconds for this to work correctly... In my post from the earlier thread I wrote: > Then you should set UTC time on that server close to (maybe 1 or 2 hours > before) midnight for the correct leap second date, e.g. 22:00 UTC on > June 30, 2012, and start ntpd on the server. > 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@leapstick:~# adjtimex --print | grep status >status: 17 > > while ntptime reports > > root@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.824 > 2012/06/30 23:59:59.000300870 -0.11565854948 > 2012/06/30 23:59:59.000996706 0.8054485 > > (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 > x86_64 GNU/Linux > > I don't know if leap seconds are handled better in more recent kernels. A very quick look at the sources of some Linux kernel versions seems to indicate that the time interpolation during the leap second has been removed and replaced by simply stepping the clock back. Appearingly this has happened starting with kernel 2.6.23, where the function time_interpolator_update() isn't called anymore by the leap second handling code in kernel/time/ntp.c. I haven't made some tests to verify that 2.6.22 still interpolates, but 2.6.23 does not, though. Regards, Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Failed to test leapsecond's handling
Hi Martin, all On 12/03/12 12:16, Martin Burnicki wrote: > In my post from the earlier thread I wrote: >> > Then you should set UTC time on that server close to (maybe 1 or 2 hours >> > before) midnight for the correct leap second date, e.g. 22:00 UTC on >> > June 30, 2012, and start ntpd on the server. Erm... I know, but I couldn't leave two hours between each two tests, so I was trying to find a shorter working interval. Unfortunately, when they didn't work, this didn't come to mind immediately. >> > I don't know if leap seconds are handled better in more recent kernels. > A very quick look at the sources of some Linux kernel versions seems to > indicate that the time interpolation during the leap second has been > removed and replaced by simply stepping the clock back. > > Appearingly this has happened starting with kernel 2.6.23, where the > function time_interpolator_update() isn't called anymore by the leap second > handling code in kernel/time/ntp.c. > > I haven't made some tests to verify that 2.6.22 still interpolates, but > 2.6.23 does not, though. I have found this, not sure how much it is related: http://forum.soft32.com/linux/PATCH-NTP-remove-clock_was_set-call-prevent-deadlock-ftopict346632.html I am rather curious why they moved away from the advised handling to go back to the stepped approach... Ciao -- bronto ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
