[ntp:questions] Re: ntp servers reporting leap second erroneously? (was: Re: questions Digest, Vol 13, Issue 38)
mayer at gis.net
Mon Oct 17 14:54:47 UTC 2005
Martin Burnicki wrote:
> Harlan, Dave,
> I've just simulated the upcoming leap second event once more using the
> current BK version which includes the patch.
> It "works as designed" now under Windows, i.e. the time is stepped back by 1
> second while the frequency correction is kept correctly.
>>From the Windows event log:
> 2005-12-31 23:55:19 ntpd 4.2.0b at 1.1417-o
> 2005-12-31 23:55:25 synchronized to 172.16.8.19, stratum 1
> 2006-01-01 00:12:30 time reset -0.973872 s
> 2006-01-01 00:16:48 synchronized to 172.16.8.19, stratum 1
> However, unfortunately the same thing happens now with my Linux client:
> Jan 1 23:53:53 ntpd: ntpd 4.2.0b at 1.1417-o
> Jan 1 23:53:53 ntpd: kernel time sync status 0040
> Jan 1 23:54:02 ntpd: synchronized to 172.16.8.19, stratum 1
> Jan 1 23:54:02 ntpd: kernel time sync enabled 0001
> Jan 1 00:15:24 ntpd: time reset -1.051926 s
> Jan 1 00:17:02 ntpd: synchronized to 172.16.8.19, stratum 1
> whereas the ntp-dev version from a few days ago just notified the kernel
> about the upcoming leap second, and the kernel handled it and logged the
> leap second event to the syslog:
> Jan 1 23:59:59 kernel: Clock: inserting leap second 23:59:60 UTC
> So I'm afraid Dave had to look at this once more.
I do have reservations about stepping the clock *BACK* by one second. I
would rather see that the clock increments more slowly until time
catches up with it since time is always supposed to be a monotonically
increasing function. This can also impact logging when tracking done
suspicious events, database timestamps, etc.
More information about the questions