Re: [Ntp] Negative leap-second?

Warner Losh <imp@bsdimp.com> Wed, 03 August 2022 00:11 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 D9B1EC1594AF for <ntp@ietfa.amsl.com>; Tue, 2 Aug 2022 17:11:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bsdimp-com.20210112.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wl_Op3aXHf8H for <ntp@ietfa.amsl.com>; Tue, 2 Aug 2022 17:11:42 -0700 (PDT)
Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65F49C13180D for <ntp@ietf.org>; Tue, 2 Aug 2022 17:10:06 -0700 (PDT)
Received: by mail-vs1-xe2f.google.com with SMTP id c3so16273553vsc.6 for <ntp@ietf.org>; Tue, 02 Aug 2022 17:10:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=NdJx2cC62Yec1oHgqQPQzaCX2NZjaZo+gKDiN//Cdqo=; b=Tq8KBNz+rBS8vBK7RZ1+UmlfBIKRdowCEsZnRbM8Rn37u3UfbK+AheyU/RMNAQcG6V yKfVewdfwGUP8PhhtzzYWKZnJXFM3T2A+EnIrT63vqHVevxuecPSpvOH6MmiK2lJD3+n 8rVOQ96eYv7INhb7pa2EVwtzyCYVlQMozCUcV2Nv9k6Z8KWEj3FDAIDUYUklsXUNYPG5 nP39iiCGKmiZoOHPi8iJlVu+lKvSFDOmBGn1jlwBSk2E761/XtiZbP/hah3m8sfEPAC0 G0nOQ7EpKWYpL9K5PmGlv+ibhvF+F/L9J+RBUtvoueeTCNqaAA9WZ227gbHeW2m36QO4 +jng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=NdJx2cC62Yec1oHgqQPQzaCX2NZjaZo+gKDiN//Cdqo=; b=xhSiT0Xfw+673zp62w2jy0SeYFZewj5tN5DWjk527sTp1MkYFIyMxDbqKCbYp/+bI4 pWT+e/10BWO9boYIIiHNKvntZXfZJ7/P7sIDhfk8GtjdmBvYetYojEeRuoanJpuVenP7 BqQVA0/XWflnUcoWBy690+nvliWuYgC4MDAy7gYo2TFsj2j6u6EqfjziPiLfxdwCl2RN ZsT7zk5Zfy6JTTCqG95f9AE7ZTdv3OFCKXSldA0du5gxctPVU0RuU4zQ44+F+gTGIVGy 5PYFtT4Yto7L4TCwDoCeX48my93ZPgL0nLzmGW3OCiDDK2Ec09cQ+EA7AmFVCTQHxorC J2eQ==
X-Gm-Message-State: ACgBeo0VGDiuoUuFn4VTuV1A+wEOkUI14IBPYN1s1kX1J2XrqE01WyRB TospYN68FWxLLI9rmEVrEhvM3KnNhcMyroTKIlopSqc0bqU=
X-Google-Smtp-Source: AA6agR7ReZiA1VMd6Fz7JNRMDvWNpejmc3LqxH1NRkrtVjpzqHhRD27kQoUnXOOqBJA90ao2SJeuZBcnTmo2YzH2mAw=
X-Received: by 2002:a67:fb8f:0:b0:373:48cd:5fc3 with SMTP id n15-20020a67fb8f000000b0037348cd5fc3mr7334694vsr.40.1659485405318; Tue, 02 Aug 2022 17:10:05 -0700 (PDT)
MIME-Version: 1.0
References: <b023985d-76c3-c6b9-3b5b-f10b3cabd2f5@pdmconsulting.net> <CAJm83bAZgW=xgkO8BAW8HFTsSkGfdQKjkdQnfkyNWRAHdVTB3w@mail.gmail.com>
In-Reply-To: <CAJm83bAZgW=xgkO8BAW8HFTsSkGfdQKjkdQnfkyNWRAHdVTB3w@mail.gmail.com>
From: Warner Losh <imp@bsdimp.com>
Date: Tue, 02 Aug 2022 18:04:46 -0600
Message-ID: <CANCZdfo=gFr31FqVu0Wg6Wz5fgawF08viSEmdg_wCqr2Zca-Hg@mail.gmail.com>
To: Daniel Franke <dfoxfranke@gmail.com>
Cc: Danny Mayer <mayer@pdmconsulting.net>, NTP WG <ntp@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000018211c05e54b0e7d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/tRI_BtLOgaBGyBbVnv0Zbxfl6EE>
Subject: Re: [Ntp] Negative leap-second?
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Network Time Protocol <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: Wed, 03 Aug 2022 00:11:45 -0000

On Tue, Aug 2, 2022, 5:19 PM Daniel Franke <dfoxfranke@gmail.com> wrote:

> I think predictions of a negative leap second are very premature, but I
> have fewer worries about a negative one than about a positive one. I've
> reviewed quite a lot of leap second handling code and never encountered any
> that gets the positive case right but the negative case wrong; programmers
> clued into the issue at all and generally clued in enough to know that
> negative ones are a possibility.
>

It's been my experience that even though they know negative leap seconds
are a possibility, they are more apt to have bugs than the positive leap
second code. I've had to fix more bugs in the negative code than the
positive code when we did testing on the GPS simulation system.

What makes me *less* worried about negative leap seconds (rather than just
> not-much-more worried) is their effect on leap-second-naive code: they make
> POSIX time jump forward rather than backward. Lots of code out there
> wrongly assumes that POSIX time can never jump backward. Code that assumes
> it can never jump forward would get broken every time someone every time
> someone suspends their laptop or pauses their VM or just puts their OS
> scheduler under a lot of load.
>

I'd worry about tiny sleeps in the kernel and hardpps() calculations
getting confused as the kernel itself jumps forward a smidge. I wouldn't
rush too fast to say there won't be some subtle problem, likely not in the
time code itself...

The history of leap second code is untested code is buggy code. And
negative leaps are way less tested than positive ones. We've had deadlocks
due to bad lock handling, leap seconds applied at the wrong time (end of
the day when viewed as uptime is a bug I fixed years ago, but that bug was
introduced in the last leap drought around 2000).

So I'd expect it will be basically ok, but less ok than a positive leap...
I would not expect fewer problems...

Warner


On Tue, Aug 2, 2022, 19:06 Danny Mayer <mayer@pdmconsulting.net> wrote:
>
>> Apparently the earth's rotation is speeding up:
>> https://www.timeanddate.com/news/astronomy/shortest-day-2022
>>
>> If we have to subtract a leap-second I think we will see failures, since
>> this is rarely if ever tested.
>>
>> Danny
>>
>> _______________________________________________
>> 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
>