Re: [Ntp] Leap second draft

[Martin Burnicki <[e-mail]>]

Kurt Roeckx wrote:
> On Tue, Apr 02, 2019 at 09:40:58AM +0200, Martin Burnicki wrote:
>> Kurt Roeckx wrote:
>>> One question I have that I can't seem to find the answer for is
>>> which second do you announce during the leap second in NTP.
>>>
>>> There was a leap second at 3692217600. Do you send:
>>> 3692217599
>>> 3692217599 (leap second)
>>> 3692217600
>>>
>>> Or:
>>>
>>> 3692217599
>>> 3692217600 (leap second)
>>> 3692217600
>>>
>>> I can see arguments for both ways, and if it's not specified
>>> somewhere yet, I think we need to specify it.
>>
>> NTP implementations I've seen just pick up the current system time, so
>> which timestamps are returned during a leap second depends on the way
>> the particular operating system handles the leap second, and e.g. ntpd
>> running on one type of operating system can behave differently than ntpd
>> running on a different type of operating system.
>>
>> So the discussion which way is the "better" one had to be done with the
>> maintainers of the OS kernel clock implementation. ;-)
>>
>> Letting an NTP daemon decide what kind of timestamp to return would
>> require that it
>>
>> 1.) uses the adjtimex()/ntp_adjtime() API calls to retrieve a timestamp
>> including some status information, and then modifies the time stamp in a
>> preferred way
>>
>> 2.) maintains its own clock beside the system clock so it could handle
>> the leap second in a different way than the kernel clock
>>
>> Solution 1.) is normally not used because adjtimex()/ntp_adjtime() take
>> longer to execute than a simple clock_gettime()
>>
>> Solution 2.) can cause additional problems if the daemon's internal leap
>> second handling differs from the leap second handling observed by
>> applications running on the particular system.
> 
> One option would be the allow both the cases, but I still think
> that should get documented.
> 
> But to be compliant with the current draft, you would need to know
> that a timestamp is within the leap second.
> 
> It can be that with the current kernel APIs, this is very hard to
> properly do, but I don't see that as a problem of the draft.

I agree, but on the other hand, what's the advantage of a draft if it is
not implemented, e.g. because the performance is degraded?

Many years ago Dave Mills suggested to implement kernel clocks in a way
that the system time doesn't have to be stepped back to insert a leap
second. Instead, it should basically be stopped during that second, but
this would result in always the same time stamp during the leap second,
so the final proposal was to increment the least significant bit of the
time stamp e.g. 1 microsecond or nanosecond whenever any application
retrieves a time stamp. This approach makes sure the system time is
always strictly monotonically increasing.

Thus, an approach like this at the kernel level would avoid many
problems with user space applications across a leap second, and some
time ago I've discussed this with one of the Linux kernel developers.

He told me it's simply too expensive (in terms of execution time) to let
the kernel check whether its time is inside a leap second, or not,
whenever any applications asks for the system time, just because this
may happen during a single second in a couple of years.

So the kernel in fact simply steps the time back at the beginning or end
of a leap second, which often causes problems with applications that
don't expect such step, but anyway it's less expensive for the kernel.

Basically the same problem arises if you call adjtimex()/ntp_adjtime()
whenever you want to get a current system timestamp. If a program like
ntpd did it the number of client requests it can handle per second would
probably be decrease, and on the other hand this wouldn't even improve
the situation of applications running on a client.

In my opinion the current mechanisms provided by the protocol to
announce and handle a leap second are sufficient, even across several
stratum levels.

What was generally missing (unless you used autokey) was a way to
propagate the current TAI/UTC offset over the network, so it's good to
have a replacement which can be used to do this in the absence of
autokey, if required, e.g. using an extension field.

A bigger problem than the protocol itself is to have a way to inject
information on an upcoming leap seconds, TAI offset, etc. reliably at
the top of the timing chain.

With reliably I mean that this must not only work as long as the OS
maintainers provide software update packages that contain a tzdata/leap
second file, but independently from firmware updates. We have discussed
this a couple of days ago.

> Assuming it's not possible to properly implement the bits
> indicating that a timestamp is within the leap second, maybe the
> draft should mention that in that case you should either not reply
> around the leap second or return that you're not synchronized.

Yes, the current behavior of ntpd to claim to be *not* synchronized for
a short interval across a leap second (as has been suggested by
Miroslav) doesn't hurt, but reduces potential problems especially with
simple clients, and I agree that *this* behavior should be documented.


Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: [e-mail]
Phone: [phone]
Linkedin: https://www.linkedin.com/in/martinburnicki/

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy