Re: [Ntp] Leap second draft

[Kurt Roeckx <[e-mail]>]

On Wed, Apr 03, 2019 at 10:41:34AM +0200, Martin Burnicki wrote:
> Kurt Roeckx wrote:
> > 
> > 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.

The other problem with a solution like that is that your time is
wrong, going from 0 to -0.5, then jump to +0.5 to go back to 0.
It would a case where you do not want to answer packets either.

> 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.

I can understand that you don't want to have such a check in
kernel code, because things that don't care about it are also
affected by it. But I don't see a problem doing such a check in
userspace as a problem. In case it's known that the kernel does a
step, it looks like you should be able known if you're in the
middle of a leap second or not without losing much performance.

An other solution is that the kernel provides a TAI interface, and
user space can then just adjust it with the TAI-UTC offset.

Anyway, I'm not arguing that we need the to be able to indicate
that a timestamp was during a leap second, just saying that there
might be solutions to properly implement the draft as it currently
is.

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

I've seen many broken ntp servers during each leap second, it takes
a long time for them to get fixed across the statum level. I think
one of the reasons is that the NTP RFC defines "00" as no leap
second, instead of not knowning it, and that the "00" wins even when
others servers have properly announced the leap second. I think that
the current draft making a distinction between the 2 cases is a good
thing, but I guess it needs to have guidance of how to actually
deal with it.


Kurt