[ntp:questions] Re: ntp servers reporting leap second erroneously?

David L. Mills mills at udel.edu
Mon Oct 17 13:14:34 UTC 2005


Martin,

As I said to your private message, your simulation has to include the 
actual leap; in other words, the real clock seen be the kernel has to 
step in order for the ntpd clock to follow it. I don't see means to do 
this in your simulation.

Dave

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[29969]: ntpd 4.2.0b at 1.1417-o
> Jan  1 23:53:53 ntpd[29970]: kernel time sync status 0040
> Jan  1 23:54:02 ntpd[29970]: synchronized to 172.16.8.19, stratum 1
> Jan  1 23:54:02 ntpd[29970]: kernel time sync enabled 0001
> Jan  1 00:15:24 ntpd[29970]: time reset -1.051926 s
> Jan  1 00:17:02 ntpd[29970]: 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.
> 
> Martin




More information about the questions mailing list