Sorry for jumping in so late. Zefram wrote: > Warner Losh wrote: >> Except that it does advance... It plays the second twice, once with >> the pending leap set, and once with it cleared I though.
The current implementation of ntpd just calls clock_gettime( CLOCK_REALTIME ) to retrieve receive and transmit timestamps, at least if kernel discipline is enabled. So which time stamps are seen across a leap second depends on the way the kernel handles leap seconds. If the kernel just steps the time back and replays the last second of the day then this is also what NTP clients get from this server. ntpd calls adjtimex() AKA ntp_adjtime() only to pass time or frequency adjustments to the kernel, as well as flags like a leap second warning, etc., or the TAI offset, if it is available. The kernel then handles the leap second automatically at the right time, depending on the implementation in the kernel. Only the return code or kernel status returned by adjtimex() these calls tells ntpd if the kernel has already inserted the leap second, or not. > In practice the flags are not that well behaved. I see the second played > twice, but the flag change is not synchronised with the jump of the > scalar time value. In the logs I have, the flag changed about halfway > through the second iteration of the second. So empirically, the two > seconds cannot be distinguished purely by means of the packet on the wire. The problem here is that ntpd has to call adjtimex() in periodic intervals. On the one hand it must not do this too often (keywords: tickless kernels, avoid waking up the CPU to save power), but on the other hand ntpd can only see after the next adjtimex() call that the leap second has passed. Of course it would be great if there was an API call which executes fast to yield a high performance, and returns a timestamp plus an associated status code consistently, in an atomic operation. On the other hand this probably requires some locking mechanism in the kernel, which is expensive with regard to the execution time of the call. Martin _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
