[Ntp] Antw: Re: Leap second draft

"Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> Mon, 27 January 2020 07:47 UTC

Return-Path: <Ulrich.Windl@rz.uni-regensburg.de>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658EE120131 for <ntp@ietfa.amsl.com>; Sun, 26 Jan 2020 23:47:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWH4siJadAKn for <ntp@ietfa.amsl.com>; Sun, 26 Jan 2020 23:47:02 -0800 (PST)
Received: from mx1.uni-regensburg.de (mx1.uni-regensburg.de [194.94.157.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1090B12012D for <ntp@ietf.org>; Sun, 26 Jan 2020 23:47:02 -0800 (PST)
Received: from mx1.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 686186000055 for <ntp@ietf.org>; Mon, 27 Jan 2020 08:46:55 +0100 (CET)
Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by mx1.uni-regensburg.de (Postfix) with ESMTP id 3F8D2600004E for <ntp@ietf.org>; Mon, 27 Jan 2020 08:46:55 +0100 (CET)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Mon, 27 Jan 2020 08:46:55 +0100
Message-Id: <5E2E956D020000A100036984@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.2.0
Date: Mon, 27 Jan 2020 08:46:53 +0100
From: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
To: imp@bsdimp.com, watsonbladd@gmail.com
Cc: Daniel Franke <dfoxfranke@gmail.com>, "ntp@ietf.org" <ntp@ietf.org>, martin.burnicki@meinberg.de
References: <CAJm83bD5Ozkpg5TpkogOW6xeeNQL3ZziLO9URM7haqN8Wrp=Wg@mail.gmail.com> <CACsn0cmZkRifrnbVbPw2=9ww+ttmbAGCW39LhT+jhDLLyU8e+A@mail.gmail.com> <d28630bc-6f3c-79d7-819d-484666cf8290@meinberg.de> <CACsn0c=Q9PaLB3qWkC7v0D760fJHu3vfCsLGOetbnMi6_MG6ig@mail.gmail.com> <CANCZdfr5Ok2X2wSjjFR=4EZaDaighx8MAPDDoOYF_rNT0Rd+iw@mail.gmail.com>
In-Reply-To: <CANCZdfr5Ok2X2wSjjFR=4EZaDaighx8MAPDDoOYF_rNT0Rd+iw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/PcBhf05N343l0uIs3aAqlhRg_4s>
Subject: [Ntp] Antw: Re: Leap second draft
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jan 2020 07:47:06 -0000

>>> Warner Losh <imp@bsdimp.com> schrieb am 24.01.2020 um 18:15 in Nachricht
<CANCZdfr5Ok2X2wSjjFR=4EZaDaighx8MAPDDoOYF_rNT0Rd+iw@mail.gmail.com>:
> On Fri, Jan 24, 2020 at 9:31 AM Watson Ladd <watsonbladd@gmail.com> wrote:
> 
>>
>>
>> On Fri, Jan 24, 2020, 7:10 AM Martin Burnicki
<martin.burnicki@meinberg.de>
>> wrote:
>>
>>> Watson Ladd wrote:
>>> > On Wed, Mar 27, 2019, 9:47 AM Daniel Franke <dfoxfranke@gmail.com 
>>> > <mailto:dfoxfranke@gmail.com>> 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
>>
> 
> Carefully reading RFC 5905 shows this to be unspecified. One can make a
> logical argument that the unsynchronized is a sound approach (I'm giving
> you data that I know I can't properly encode because ntp timestamps can't
> encode leap seconds), but it's not mandated specifically that I could find.
> And it's a tricky problem absent some kind of quiet period around a leap
> second because the data is ambiguous. It's made more so because the only
> well defined operations on the timestamps, according to the RFC, is to
> subtract them to get a time phase delta measurement.

I was just thinking: (assuming the long batle with designing proper extension
fields is over)

When a (new) server would add an "leap second in progress" extension field,
the (new) clients could simply ignore the timestamp if they feel like that.
For regular leap second processing that extension field would be set just
during the actual leap second processing, while for "leap smear server" it
could be set until leap smearing is done.

Or maybe have two different "leap second in progress" indicators.

BTW: How about adding an extension field that specifies the time and type of
the next leap second to occur?

Regards,
Ulrich

> 
> Warner
> 
> 
>> Martin
>>
>>> --
>>> Martin Burnicki
>>>
>>> Senior Software Engineer
>>>
>>> MEINBERG Funkuhren GmbH & Co. KG
>>> Email: martin.burnicki@meinberg.de 
>>> Phone: +49 5281 9309-414
>>> 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 
>>> <https://www..meinbergglobal.com>
>>> Training: https://www.meinberg.academy 
>>>
>>> _______________________________________________
>> ntp mailing list
>> ntp@ietf.org 
>> https://www.ietf.org/mailman/listinfo/ntp 
>>