Re: [Ntp] Antw: Re: Leap second

Warner Losh <imp@bsdimp.com> Fri, 24 January 2020 15:32 UTC

Return-Path: <wlosh@bsdimp.com>
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 27386120154 for <ntp@ietfa.amsl.com>; Fri, 24 Jan 2020 07:32:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bsdimp-com.20150623.gappssmtp.com
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 v1Cy0-6IRSW2 for <ntp@ietfa.amsl.com>; Fri, 24 Jan 2020 07:32:09 -0800 (PST)
Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B8A912003E for <ntp@ietf.org>; Fri, 24 Jan 2020 07:32:08 -0800 (PST)
Received: by mail-qt1-x836.google.com with SMTP id c24so1790947qtp.5 for <ntp@ietf.org>; Fri, 24 Jan 2020 07:32:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BkCutt41YThERSTq0hFbcgSnwE3UVL+U9d7ftUvQkPI=; b=mpINVRDQPLB5LVIexmVZbn4RzXw+4jp4TNNh2FcTMJwDyJ2I3c+UlEtLPIMHA6S+gl c5c2nBvMTU3D3hn3IBULdsaNvg8Y7hseowimboNU1Wdb0vIIC+/WERg+ZbNZl1wF0aUH I59I+wCYC/z2LPloSDXxWodvl1bNcMUv9RsH/TdS6UJR2BhJ52o/rn+lM+aTLi1icIJ7 PBlSxQFXx38I5s6Tn7I60bb1bgophf1YbDQ3fOy7JgqC16NQkFYSu42ZMN8XIvEbYIbi 7A81Agblg7jUJpB84b7qEhB3dgRsLDpf9k2LslUKyJehCoR0buNx6Z6VLpmFV2jxEFAA Ms/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BkCutt41YThERSTq0hFbcgSnwE3UVL+U9d7ftUvQkPI=; b=ooMDE9xxdWxt7HfGn9ylPlocloc37R2HUhwbxdQEgS/BKYLL0vm1t1HL0jllPVdlAQ 5+3pBkvAX6UhguyEX0+Go1n4sCYGxbvEN2C6T8q3l2FtK/o/He6TziVM3Soyg6QEbdLs +eQR83RNrz4q8uRWs1DLd77oVfMaTticJrIPrSkVKjKdc5VXwGhnR1UrxYOxNcnnZKSu Cc1/Df+k1Xn4hZAPkfOmHrv4wg1gQcJd4mzZREhlZ3m6z4VgBoxZhQVIVYZNdmuAnIKk qFDdQVLFzlyk3jZVy/piZ1dh0p3CpeQprgGK4aq07VKI+Wcnf+/g3YhAgaMyYo3MPpIj Sp+w==
X-Gm-Message-State: APjAAAWOD5ff2R/MXB8eNYfsfGAdiwZSLWp44sG6b1GgaBvgrsCR7SwZ jPIk24oUQtGOt1Uj0V6moaXjUtNsk4trgIlLtnOv3YkK
X-Google-Smtp-Source: APXvYqzMRsvbGQBGAeRERIF5Q5wQaHbvELWkvZamepvmPOfRTdJXdnhednk02KT90nlkKFHjEo5h5i6YD6Rx4ntffj0=
X-Received: by 2002:ac8:48c9:: with SMTP id l9mr2767968qtr.242.1579879927615; Fri, 24 Jan 2020 07:32:07 -0800 (PST)
MIME-Version: 1.0
References: <20200123235232.BB54440605C@ip-64-139-1-69.sjc.megapath.net> <5E2AB233020000A1000367EF@gwsmtp.uni-regensburg.de>
In-Reply-To: <5E2AB233020000A1000367EF@gwsmtp.uni-regensburg.de>
From: Warner Losh <imp@bsdimp.com>
Date: Fri, 24 Jan 2020 08:31:56 -0700
Message-ID: <CANCZdfqNVGiOdZncUkJD5yAR8DvCBiWRnNZei=wU4tV+WW0f-Q@mail.gmail.com>
To: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
Cc: "ntp@ietf.org" <ntp@ietf.org>, Hal Murray <hmurray@megapathdsl.net>
Content-Type: multipart/alternative; boundary="000000000000dfa2e9059ce475de"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/FaN7fV4YpbT0Lfwa071tuvIxkVo>
Subject: Re: [Ntp] 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: Fri, 24 Jan 2020 15:32:11 -0000

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.

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

Warner