[LEAPSECS] Time math libraries, UTC to TAI

[Martin Burnicki]

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