Re: [Ntp] Leap second draft

[Miroslav Lichvar <[e-mail]>]

On Fri, Mar 29, 2019 at 08:57:42PM +0100, Daniel Franke wrote:
> 1.2.  The Leap Indicator field
> 
>    NTP packets include a Leap Indicator field which warns receivers of
>    an upcoming insertion or deletion of a leap second.  [RFC5905]
>    specifies that this field warns "of an impending leap second to be
>    inserted or deleted in the last minute of the current month".

RFC 5905 actually says both "current month" and "current day". I think
the leap field was supposed to be compatible with NTPv3 (it's not
mentioned in the RFC as an incompatible change - unlike the refid
field) and both instances in the document should say "day". I've
submitted an errata for this couple years ago.

>    The Era Number subfield gives the era number of the Receive
>    Timestamp.  The Reference Timestamp always precedes the Receive
>    Timestamp, and the Transmit Timestamp always succeeds the Receive
>    Timestamp.

I don't think this is always the case. It's not required by RFC 5905.

Some reasons for a TX timestamp not being after RX:
- low-precision clock (randomization of low-order bits may, but
  doesn't have to enforce the order of generated timestamps)
- clock stepped between RX and TX (e.g. in symmetric mode)
- very simple server using a single timestamp for both TX and RX
- interleaved mode (in this case it would be unusual to see RX < TX)

>       F: When set, indicates that the Reference Timestamp was captured
>       during a leap second.
> 
>       R: When set, indicates that the Receive Timestamp was captured
>       during a leap second.
> 
>       X: When set, indicates that the Transmit Timestamp was captured
>       during a leap second

This sounds nice, but I'm curious if it can actually be implemented on
current systems. One issue is that the system clock may not be stepped
exactly at 00:00:00.000000000. It may happen few microseconds or even
milliseconds later.

Timestamps captured by ntp_gettime(), which gives also the clock
status code, could be better at least in theory, but it may be much
slower than clock_gettime() and there is no way to get this
information for timestamps captured by the kernel (e.g. with the
SO_TIMESTAMP socket option).

To me it would make more sense to specify that clients should ignore
any measurements that have a timestamp that is too close to the leap
second and servers should respond with "unsynchronized" leap bits
around leap second. Some implementations already do this.

-- 
Miroslav Lichvar