Re: [Ntp] Leap second draft

Warner Losh <imp@bsdimp.com> Tue, 02 April 2019 03:51 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 287141200F5 for <ntp@ietfa.amsl.com>; Mon, 1 Apr 2019 20:51:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 mAkzzfGs-8MA for <ntp@ietfa.amsl.com>; Mon, 1 Apr 2019 20:51:38 -0700 (PDT)
Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 53F3E12001E for <ntp@ietf.org>; Mon, 1 Apr 2019 20:51:38 -0700 (PDT)
Received: by mail-qt1-x82a.google.com with SMTP id w30so13412210qta.8 for <ntp@ietf.org>; Mon, 01 Apr 2019 20:51:38 -0700 (PDT)
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=DowJXNAnvgw5gD4lK39s7QH174JUtxALvNSm5Xj23Ok=; b=VSBr/97UAJZhhX9aSi2EqoNxKhguf5bkKZAVqHsAtZAqCC2ERKvJ5sChiChOQOdUcz pkYm3vjZUNx1jw92i1BXLZ6iLrE2jKI7Jd8Tr77IbxWBqBnWL/JlyfQmdKfVEXr41e8B r3nUMb7laZExbYThc1Sgdjq5/PtsL5pjKiAi1zQndZNGjyOMG5oWko+qOxyAw9gNT6dL ipIjeKFadHdxMpRf/DZbYNaqn20PZOGKHdI42Ijwo6DKcVrlX9uO7wTvZWBnmF0oDLFM r4FmsH3LuZ64cdgsRXRaywEcTkmTn9RtJc6ReNRqFB5WhyFecOpzLTk/I6ijxq09MXiv 0Shg==
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=DowJXNAnvgw5gD4lK39s7QH174JUtxALvNSm5Xj23Ok=; b=XiU26OPgMdMRdt24jQcueheW6tC3athD/ovgEhrbbJ1S2ngwFE1oPDyNkzETtyEThY Wm9fjNUX3ZI1MKUJ/nQZy5Ounz253ZDM40wjFLs6C/05CUQBh6ys919gkLKzGBPTKpf/ sPj6IJMiMvywO72gi1tVlHOAt776ELNYlUDRii3NybJ+s786Mt0u7l3spvZmKJhTXx6V ktviTJH2ZWHx8xhSD8gm7FscYTqFuoj7f3phiwL/vL61Sy1zpwiK8U/vkhxd/CBdhYXQ 0Ix9rEEVbFkcZNSBiqiarNIBBnZYsNhrzrx1Gzn53upPOyvw38K9COKaX/Ykz73Hp0DX XG4Q==
X-Gm-Message-State: APjAAAXC8CButOG5uBZqplqW/16eA5HFnjDOUoIj1pmISLW2WjySHHAP SWyfzWaBIyOXnVVvvpVmjIZeQpu8sUWPqYZZiAZAaA==
X-Google-Smtp-Source: APXvYqwg0M7v21jYTgz4qNZwzO5u407sSVqIyGH6Yj6pHUKnfe49MEW5pdv+gevuSoOynvX84F1LBk/HB2Myq34/yAg=
X-Received: by 2002:ac8:5493:: with SMTP id h19mr54717871qtq.23.1554177097084; Mon, 01 Apr 2019 20:51:37 -0700 (PDT)
MIME-Version: 1.0
References: <CAJm83bD5Ozkpg5TpkogOW6xeeNQL3ZziLO9URM7haqN8Wrp=Wg@mail.gmail.com> <CAJm83bCbVzO3NNCbjTy+O_16T7DBeA7O6018WWGu_-GyuN-8UA@mail.gmail.com> <20190330045928.GA31550@ucolick.org> <20190330133348.GA20646@ucolick.org> <20190330152948.GI7706@roeckx.be> <CAJm83bB6BF4_Ked5rVRdGmgYECz5gDrb+_7JeOUe1Lmq2ysVQQ@mail.gmail.com> <CANCZdfrbJhVsVJrsw5QRxDWmpHLJdsMMXi=Z=XvJDi1bGvnk=w@mail.gmail.com> <CAJm83bCRW4dDcZZFL1kqhKyWH_PszGjvmqyyt_E1HgOPw_bktQ@mail.gmail.com> <20190330194428.GA3572@ucolick.org> <20190330235249.GK7706@roeckx.be> <CAJm83bBiY0iEm_TShJyrUepdw=mrDx3HVK+g9Tj7WpR79Knt1Q@mail.gmail.com> <CANCZdfrV_nH9OUCuJn2WoPqONcY+pMa017du4mzoZ_kaZfoZPQ@mail.gmail.com> <CACsn0cnCX_qDTKKr=9UO=8auEq0XMDZnhXtyKDYgAgC=FrucBg@mail.gmail.com> <CANCZdfqfxRjs+4R-VPtPQNexXRjjNrhCx6nZQ3fDpUYuADz+hg@mail.gmail.com> <CACsn0cnWrcTeBAvaWpM+p0W-4ftn48BG7jZXZydnrS1qcavyOA@mail.gmail.com>
In-Reply-To: <CACsn0cnWrcTeBAvaWpM+p0W-4ftn48BG7jZXZydnrS1qcavyOA@mail.gmail.com>
From: Warner Losh <imp@bsdimp.com>
Date: Mon, 01 Apr 2019 21:51:23 -0600
Message-ID: <CANCZdfoS-CZW+u5nCkUyKV=bEXbVxXWAu0HrB87rCh6XbZ0VJw@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Cc: Daniel Franke <dfoxfranke@gmail.com>, Steve Allen <sla@ucolick.org>, NTP WG <ntp@ietf.org>, Kurt Roeckx <kurt@roeckx.be>
Content-Type: multipart/alternative; boundary="000000000000ca45f00585840d94"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/aTBRUp5G7hbLhh2XQ_5YyRLypMY>
Subject: Re: [Ntp] 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: Tue, 02 Apr 2019 03:51:41 -0000

On Mon, Apr 1, 2019, 8:06 PM Watson Ladd <watsonbladd@gmail.com> wrote:

> On Mon, Apr 1, 2019 at 6:35 PM Warner Losh <imp@bsdimp.com> wrote:
> >
> >
> >
> > On Mon, Apr 1, 2019 at 7:14 PM Watson Ladd <watsonbladd@gmail.com>
> wrote:
> >>
> >> On Sat, Mar 30, 2019 at 8:02 PM Warner Losh <imp@bsdimp.com> wrote:
> >> >
> >> >
> >> >
> >> > On Sat, Mar 30, 2019, 6:36 PM Daniel Franke <dfoxfranke@gmail.com>
> wrote:
> >> >>
> >> >> On Sat, Mar 30, 2019 at 7:53 PM Kurt Roeckx <kurt@roeckx.be> wrote:
> >> >> > Anyway, I think we should avoid defining what things like NTP
> >> >> > time, UTC and TAI is. They should all have external definitions
> >> >> > we can just point to.
> >> >>
> >> >> Where the definitions are normative, sure. But as Steve's infodumps
> in
> >> >> this thread rather vividly illustrate, readers need a comprehensible
> >> >> summary; we can't just incorporate the whole body of relevant
> >> >> standards by reference and leave it at that. The statements in the
> >> >> background section aren't normative, and should be accurate but don't
> >> >> have to be comprehensive. And I won't be worried if, for example, the
> >> >> quoted definition of an SI second gets superseded a month after the
> >> >> RFC is published, because the quote isn't there to be authoritative;
> >> >> it's there to illustrate what such a definition can look like.
> >> >
> >> >
> >> > The current definition doesn't help. A reference to the BIPM with the
> latest definition doc at the time of publication would suffice. The hard
> part is getting the right pointers.
> >> >
> >> > It doesn't matter what a SI second is. NTP counts them and exchanges
> that count. They could be anything. People have done GPS times (also SI
> seconds) and UT1 times (solar variable length seconds). They've even done
> Julian Time NTP.. Now obviously these different time scales won't
> interoperate, but they are fine so long as everybody exchanging time agrees
> on the rules for the time scale. That brings us to UTC. It's the odd man
> out. It ticks at a fixed rate, and occasionally has seconds inserted into
> it. UTC is related to TAI by a stepwise function that always increases or
> decreases by 1. This increase or decrease historically has always been
> December or June, but technically could be at the end of any month. UTC is
> synchronized to UT1 every so often based on a set of rules. The current
> rule is that | DUT1 | must remain < .9s so you move it when you think it
> might exceed .9 before the next chance to move it. Other rules are
> possible, but just like leaps at the end of any other month than December
> or June not likely.
> >>
> >> I've tried citing the BIPM definitions, but they are specified in
> >> years, months, days, hours, minutes, seconds, and fraction of second,
> >> while NTP uses seconds and fraction of seconds. Then there is the
> >> whole document access issue.
> >
> >
> > The definition of an SI seconds has nothing to do with years, etc.
>
> Correct, but UTC timestamps are specified with a representation based
> on hours, minutes, and seconds.
>

There are two standards. What defines an si second. And also how UTC labels
the seconds. TF460 is for the latter. I don't have a good reference for the
former, but we don't have to repeat the current SI definition because that
is not relevant to NTP. It just exchanges counts of seconds, whatever they
are, and the number of hyper fine transitions is never an issue for the
protocol. It is an issue if you are building a cesium standard and almost
never at any other time.

The mapping of a number to the UTC labeling of the second is defined in the
NTP RFC. It is relevant because the mapping is unique to NTP. Also relevant
is how UTC labels the seconds, since it is totally weird to the
uninitiated.

Also, what to do around the leap second, where UTC is totally weird and
irregular compared to a traditional time scales is highly relevant. Those
details matter and are of critical importance to implementing NTP in an
interoperable way. Even the basics are worth repeating. All the more
because supposedly obvious details not worth mentioning in prior docs are
done in a diversity of ways.

Although I've been nitpicky, it comes from a decade of doing high precision
time and frequency work and having to interoperate with all the different
choices... I'm so glad to see this get spelled out. Thank you so much for
doing this...

Warner

>
> > Warner
> >
> >>
> >> >
> >> > So, it makes sense to just hit these points, and give pointers to the
> underlying details, which don't matter.
> >> >
> >> > Warner
> >> >
> >> >> _______________________________________________
> >> >> ntp mailing list
> >> >> ntp@ietf.org
> >> >> https://www.ietf.org/mailman/listinfo/ntp
> >> >
> >> > _______________________________________________
> >> > ntp mailing list
> >> > ntp@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/ntp
> >>
> >>
> >>
> >> --
> >> "Man is born free, but everywhere he is in chains".
> >> --Rousseau.
>
>
>
> --
> "Man is born free, but everywhere he is in chains".
> --Rousseau.
>