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 [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
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
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
