Marco Marongiu wrote:
On 12/01/15 06:10, William Unruh wrote:
I also admit I do not know how windows impliments leap
seconds.
The Windows operating system by itself is not aware of any leap seconds,
as far as I know.
Due to this fact, I opened a bugzilla issue back in 2005
https://bugs.ntp.org/show_bug.cgi?id=508
At that time ntpd *only* passed the leap second warning to the OS kernel
(and of course to NTP clients), but on OS types which didn't provide a
kernel API which supports this ntpd just did nothing by itself to get
the leap second handled properly by the OS.
Instead, it would detect a sudden 1 s offset after the leap second, and
step the time back by 1 s about 15 s after the leap second, just as it
does with normal time steps between 128 ms and the panic threshold
(~1000 s). This also includes a flushing of ntpd's internal filters, as
with a restart of ntpd.
Windows was just one of those OSs, but a very popular one with lots of
installations running ntpd instead of w32time, so many NTP users would
have to suffer from the time being off by 1 second for several minutes,
and then be stepped *back* by 1 s.
You know, stepping the time back can very badly affect applications like
data bases, etc.
As you can read in the comments to bug 508, especially comment 14, DLM
anyway refused to support this in the stock NTP code:
https://bugs.ntp.org/show_bug.cgi?id=508#c14
I don't have a reference, but I remember that at the time of the latest
leap second I read that Windows will half the clock speed at 23:59:59 so
that it reaches 00:00:00 at the right time. It pays the price of being
wrong for two seconds in order to save the system from a discontinuity.
I'm also maintaining the driver software for Meinberg PCI cards, and
when I opened bug 508 I already had some code which tried to work
arround the missing leap second support in Windows (this means, AFAIK
there is no API where a program can notify Windows that a leap second is
approaching, so that windows can handle it by itself, like most *ix
kernels do).
The workaround was indeed to slew down the system clock to half speed
for 2 seconds, which means that after those 2 seconds the system time
has only gained 1 second, and thus matches again the normal time after
the leap second.
Since the system time always kept increasing over the correction there
were no bad affects for applications due to time being stepped back.
I ported my code to NTP and it was in some Windows-only section of the
NTP code. However, it was hard to get this committed and a new NTP
version be released, but it was already a month or so before the leap
second event, so we at Meinberg decided to roll out an own version of
NTP, based on the normal tar ball, but with a patch for leap second
support in Windows.
We (Meinberg) made the code available at the beginning of December,
2005, and called the version of the NTP installer for windows "Xmas
Edition". ;-)
This was a variant of ntp-4.2.0b, see also:
http://bugs.ntp.org/show_bug.cgi?id=686
It still took some time until my patch made it into the official NTP
sources, see also bug 686 mentioned above.
Some years after bug 508 DLM suddenly changed his opinion. He revised
the common leap second code and implemented support for leap seconds on
systems without appropriate kernel API, which would now simply step the
system time back at the leap second event time. This was in the
developer version 4.2.5, i.e. between the stable releases 4.2.4 and 4.2.6.
So at least it wouldn't take 15 minutes or so until the correction was
made, and ntpd's filters weren't flushed, but this broke the
Windows-specific leap second code I had submitted before.
At that time I was very busy and not closely looking at the evolution of
the NTP code, but I became aware of this by a new comment to the old bug
508:
https://bugs.ntp.org/show_bug.cgi?id=508#c25
Fortunately Dave Hart had some time to have a closer look at this, and
fix it for 4.2.6, so unless something has been broken again in the mean
time it should be fixed in 4.2.6 and later, and should work correctly.
I'm planning to do some testing soon to verify this.
Martin
--
Martin Burnicki
Meinberg Funkuhren
Bad Pyrmont
Germany
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
