Re: [Ntp] Leap second draft

[Watson Ladd <[e-mail]>]

On Fri, Jan 24, 2020, 7:10 AM Martin Burnicki <[e-mail]>
wrote:

> Watson Ladd wrote:
> > On Wed, Mar 27, 2019, 9:47 AM Daniel Franke <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     I'm writing up an I-D clarifying how NTP implementations are to
> behave
> >     in proximity to a leap second and also introducing an extension field
> >     that provides better leap-second-related information than is
> >     expressible using header fields alone, including giving the TAI-UTC
> >     offset.
> >
> >     Karen, you mentioned a possible CfA for
> >     draft-stenn-ntp-extended-information if Harlan revises it to comply
> >     with RFC 7822 (-04 does not appear to comply). Our two drafts are
> >     partly redundant in purpose since they both provide TAI-UTC offset
> and
> >     we won't want to adopt both. Of course I think mine is the one we
> >     should adopt, but I'll strive to get a -00 submitted promptly so that
> >     they can be considered side-by-side without unduly delaying Harlan's
> >     CfA.
> >
> >
> > Apologies for the necromancy but someone at work just asked me which
> > second is repeated in an NTP timestamp and to make sure all our sources
> > use the right one.
>
> Strictly speaking, it depends on the operating system.
>
> A process like ntpd notifies the kernel that a leap second is coming up
> at the end of the day, and the kernel handles the leap second. So it
> depends on the implementation in the kernel whether the last or the
> first second is repeated to insert a leap second.
>
> ntpd just picks up the current system time from the kernel and sends it
> to its clients.
>
> It only detects that the leap second event has passed when it queries
> the kernel time stat the next time. If clients retrieved the time from
> ntpd after the leap second has finished but before ntpd has updated the
> kernel time status the leap bits can be wrong.
>
> This is one of the reasons why ntpd sends leap bits "unsynchronized" for
> a short time around the leap second. This doesn't hurt or confuse the
> client.
>

Is this mandated by RFC 5905?

If not, should it be/should the behavior be more precise?

I realize there may be a bug around this when using a separate server
process: my gut says one measurement off by a second is insignificant since
the maximum adjustment in response, but there may be other issues I'm not
thinking about.


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