From nobody Tue Oct 19 08:57:58 2021 Return-Path: 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 CD4C23A0926 for ; Tue, 19 Oct 2021 08:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, T_SPF_TEMPERROR=0.01] 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 RJajt6boysxu for ; Tue, 19 Oct 2021 08:57:49 -0700 (PDT) Received: from chessie.everett.org (chessie.everett.org [IPv6:2001:470:1:205::234]) (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 7EFC83A0922 for ; Tue, 19 Oct 2021 08:57:45 -0700 (PDT) Received: from [192.168.1.193] (pool-108-26-179-179.bstnma.fios.verizon.net [108.26.179.179]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 4HYdgB5PnszMNYM; Tue, 19 Oct 2021 15:57:42 +0000 (UTC) Message-ID: <4cfe73c5-baee-db8e-549f-2088067dcaf6@pdmconsulting.net> Date: Tue, 19 Oct 2021 11:57:41 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Content-Language: en-US To: Tony Finch , Hal Murray Cc: NTP WG References: <20211015210250.6330328C0F3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> <2ee63d83-cde0-4665-52e1-5fa0d18325e@dotat.at> From: Danny Mayer In-Reply-To: <2ee63d83-cde0-4665-52e1-5fa0d18325e@dotat.at> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ntp] Smearing X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2021 15:57:56 -0000 On 10/19/21 11:47 AM, Tony Finch wrote: > Hal Murray wrote: >> I think the protocol should use TAI and make available the leap info. >> >> That means an NTP client will need to know if it should smear. >> >> Plan A is to put that info in a flag in /etc/smear or such so that other >> programs can also use it, perhaps to unsmear or perhaps just to print a >> warning message when log files do/don't smear. >> >> Plan B would be to put that info into the kernel. There are spare slots in >> struct timex and struct ntptimeval. Then a flag in ntp.conf could tell ntpd >> to smear and it could pass that to the kernel. > Both plans don't answer the question of how the client gets the correct > configuration. Smearing is (typically) a feature of a data centre > environment and each client implicitly gets a time that matches its > neighbours by using the local NTP servers. > > When there's a mixture of NTP4 and NTP5 clients, how can you be sure that > they get the same time? I think an NTP5 server should have some way to > say, "if you were talking NTP4 to me I would give you a smeared time", so > that an NTP5 client can match its neighbours. > >> -------- >> >> The next leap info is big enough that I don't want it in the basic >> packet format. > It doesn't need to be more than 4 bytes. > > According to TF.460 (the definition of UTC) leap seconds can only happen > at the end of a month, so the leap indicator only needs to count months. > > Leap seconds will no longer work when the earth is turning slowly enough > that we need one at the end of every month; we expect that to happen > before the year 4200, at which point DTAI will be about 4 hours. > > https://www.ucolick.org/~sla/leapsecs/dutc.html > > If you allow 15 bits for the count of months since 1972, that lasts until > after the year 4700. 14 bits for DTAI is over 4.5 hours; it might be > wise to add a sign bit in case things get really weird. > > That leaves 2 bits spare which is just enough for the leap direction. > (Though it would be handy to have another bit to indicate smearing.) > > Tony. I agree. My proposal includes a month count and a leapsecond count. A zero for both month count and leapsecond count indicates that the values are unknown. It also indicates if there is a leapsmear in progress, the type of smearing done (there are a number of different ones) by including a smearing ID. The client can then choose whether or not to follow that smearing type. Danny