Martin,
No fair on the bug, which has been there probably most of the seven
years since the last leap.
Can you tell your radio to step UTC at the same time the system kernel
implements it after being so advised by ntpd?
I think you misunderstand how the kernel implements the leap. The ntpd
does not implement the leap; the kernel does. The kernel does not step
the clock. Please see the white paper "The NTP Timescale and Leap
Seconds" on the NTP project page for a detailed explanation.
Dave
Martin Burnicki wrote:
Dave,
David L. Mills wrote:
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.
I'm not quite sure that I understand correctly what you mean.
I have a kind of radio clock which can be used as a refclock for ntpd. I do
not only set up the date and time to shortly before the time of leap second
insertion, I can also configure that device to pass the leap second
announcement to ntpd.
I have verified using ntpq that server's ntpd is correctly detecting the
leap second announcement, set its internal leap bits to 01 and also sends
leap bits 01 to the clients.
With the ntpd code from a few days ago I could see that the Linux kernel did
receive the announcement and handle it well whereas the Windows version
didn't. The current ntp-dev version doesn's seem to notify the Linux kernel
anymore, so ntpd has to do a time step some minutes later like under
Windows.
Martin
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
