[ntp:questions] Re: ntpd and leap seconds on Windows
martin.burnicki at meinberg.de
Thu Oct 13 16:35:59 UTC 2005
Michael (or Arthur ?),
I've just finished some leap second tests using a refclock which simulates
the leap second insertion. As soon as the NTP server daemon (a ntp-dev
version, not quite the latest) has seen the leap second announcement all
the packets to the clients contain the leap second announcement. So this
works well, exactly as designed. But see below.
Arthur.Porkchop at exemail.com.au wrote:
> Perhaps I misunderstand, but on Unices which implement David Mill's
> kernel timekeeping model, on the day of a leap second, ntpd sets a flag
> in the kernel advising that a leap second has to be inserted. The
> kernel clock then adds/deletes a second as necessary at the appropriate
> time. You can see the state machine that handles this in Linux in
> kernel/timer.c; this is all described in section 3.3 of David Mill's "A
> Kernel Model for Precision Timekeeping".
My Linux clients receive the announcement and account for the leap second.
Recent kernels may note this in the syslog, e.g. a 2.6.11 kernel:
Jan 1 00:59:59 pc-martin5 kernel: Clock: inserting leap second 23:59:60 UTC
However, I've als seen older Linux kernels which seem to handle the leap
second correctly but don't create that syslog entry.
> My question was whether Windows implements the leap second state
> machine, and if not, whether the Windows port of ntpd tries to work
> around this by forcing a step shortly after the leap second.
Unfortunately at least the recent ntp-dev version does not. Here are the
messages from the Windows system event log, where 172.16.8.19 is my
dd.mm.yyyy hh:mm:ss info
31.12.2005 23:47:01 ntpd 4.2.0b at 1.1414-o Oct 13 13:01:28 2005
31.12.2005 23:47:09 synchronized to 172.16.8.19, stratum 1
01.01.2006 00:12:40 time reset -0.972420 s
01.01.2006 00:12:40 frequency error -910 PPM exceeds tolerance 500 PPM
01.01.2006 00:21:05 synchronized to 172.16.8.19, stratum 1
01.01.2006 00:32:57 time reset +0.600116 s
01.01.2006 00:35:48 synchronized to 172.16.8.19, stratum 1
So the NTP daemon steps the time 12 minutes after the time of leap second
insertion. Then it complains that the frequency error was out of range, and
about 8 minutes later steps the time again. 35 Minutes after the leap
second insertion the system time has been synchronized again.
This is not very gracefully, and I'm afraid this not only happens under
Windows but also under other OSs/OS versions which don't provide kernel
support for leap seconds.
Normally it's the task of the system clock to handle leap seconds, but as
far as I remember earlier versions of ntpd also did handle this more
gracefully, so I'm going to open an issue on bugzilla on this.
More information about the questions