Re: [Ntp] Leap second draft

[Kurt Roeckx <[e-mail]>]

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.

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.


Kurt