[Ntp] Antw: Re: Antw: Re: Leap second

"Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> Mon, 27 January 2020 07:24 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 9089F12008C for <ntp@ietfa.amsl.com>; Sun, 26 Jan 2020 23:24:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id mdISfxZozBNi for <ntp@ietfa.amsl.com>; Sun, 26 Jan 2020 23:24:28 -0800 (PST)
Received: from mx2.uni-regensburg.de (mx2.uni-regensburg.de [IPv6:2001:638:a05:137:165:0:3:bdf8]) (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 02FA2120044 for <ntp@ietf.org>; Sun, 26 Jan 2020 23:24:28 -0800 (PST)
Received: from mx2.uni-regensburg.de (localhost []) by localhost (Postfix) with SMTP id 228876000059 for <ntp@ietf.org>; Mon, 27 Jan 2020 08:24:26 +0100 (CET)
Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de []) by mx2.uni-regensburg.de (Postfix) with ESMTP id D33C7600004D for <ntp@ietf.org>; Mon, 27 Jan 2020 08:24:25 +0100 (CET)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Mon, 27 Jan 2020 08:24:25 +0100
Message-Id: <5E2E9028020000A10003696F@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.2.0
Date: Mon, 27 Jan 2020 08:24:24 +0100
From: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
To: <imp@bsdimp.com>
Cc: "ntp@ietf.org" <ntp@ietf.org>, "Hal Murray" <hmurray@megapathdsl.net>
References: <20200123235232.BB54440605C@ip-64-139-1-69.sjc.megapath.net> <5E2AB233020000A1000367EF@gwsmtp.uni-regensburg.de> <CANCZdfqNVGiOdZncUkJD5yAR8DvCBiWRnNZei=wU4tV+WW0f-Q@mail.gmail.com>
In-Reply-To: <CANCZdfqNVGiOdZncUkJD5yAR8DvCBiWRnNZei=wU4tV+WW0f-Q@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/X8hEROpZKtg9knkq-pNF295guu4>
Subject: [Ntp] Antw: Re: Antw: Re: Leap second
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:24:29 -0000

>>> Warner Losh <imp@bsdimp.com> schrieb am 24.01.2020 um 16:31 in Nachricht
> On Fri, Jan 24, 2020 at 2:00 AM Ulrich Windl <
> Ulrich.Windl@rz.uni-regensburg.de> wrote:
>> >>> Hal Murray <hmurray@megapathdsl.net> schrieb am 24.01.2020 um 00:52 in
>> Nachricht <20200123235232.BB54440605C@ip-64-139-1-69.sjc.megapath.net>et>:
>> > Warner Losh said:
>> >> NTP timestamp repeats the last second of the day. Once without the leap
>> bit
>> >> set and then again with it set.
>> >
>> > Which bit is that?  I don't know of a single "leap bit" in the header.
>> >
>> > There is a 2 bit header field with: normal (no leap), and add+del (leap
>> > pending) states.  The 4th state is used for non‑in‑sync.  Assuming you
>> meant
>> > "bits" rather than bit, then the on‑off is backwards.  I expect it to be
>> > sending leap‑pending for most of the day, then send normal (no
>> leap‑pending)
>> > for the repeated last second of the day.
>> >
>> > ‑‑‑‑‑‑‑‑
>> >
>> > I just looked at some code and found:
>> >                 if (leap_sec_in_progress) {
>> >                         /* always send "not sync" */
>> >                         xmt_leap = LEAP_NOTINSYNC;
>> >                 }
>> I wonder whether this makes much sense. Probably easy to implement, but
>> maybe
>> the server just should not respond during the leap second. Preferrable it
>> should just sent the "correct" response.
> And what, exactly, is the "correct" response? There's no unique encoding
> for the leap second as an ntp timestamp.

I think the problem is that the LI (Leap Indicator) is used for two different
1) Leap second annopuncement (ahead of time)
2) Performing the leap second (Kernel clock status)

So the NTP timestamp needs extra state information being related to the exact
second as the POSIX-based time stamp is not pecifying the correct time.

> Maybe not responding is proper, since there will be a retry in a second or
> so. But if there's any kind of skew between machines, a time exchange
> across a leap second is going to lead to a large error. Thankfully the
> error filter will filter that out, but still...

That was my other thought: Either delay the response until leap second is done
(which will consume a lot of memory in the daemon), and the response will be
discarded in the client most likely. So not responding may seem the better
decision, but still this might give the impression that there is a connectivity
problem with the server...

> Warner