Michael (or Arthur ?), you're right.
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. [EMAIL PROTECTED] 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 timeserver: dd.mm.yyyy hh:mm:ss info ---------------------------------------------------------------------- 31.12.2005 23:47:01 ntpd [EMAIL PROTECTED] 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. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
