[Ntp] Roughtime time resolution and timestamp format
Marcus Dansarie <marcus@dansarie.se> Tue, 02 April 2024 19:41 UTC
Return-Path: <marcus@dansarie.se>
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 F3F97C14CF12 for <ntp@ietfa.amsl.com>; Tue, 2 Apr 2024 12:41:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=dansarie.se
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 Gd80OQWzOk_V for <ntp@ietfa.amsl.com>; Tue, 2 Apr 2024 12:41:37 -0700 (PDT)
Received: from mail.dansarie.se (mail.dansarie.se [185.82.126.120]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 3531AC14CEFD for <ntp@ietf.org>; Tue, 2 Apr 2024 12:41:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dansarie.se; s=mail; t=1712086537; bh=O716MMzfvc2FaT+EOq2n5Ympq9Ay4QLWigNBH53h1xQ=; h=Date:From:Subject:To:From; b=nKOAGEaffzTe/bHi/boWH6c+FjPHQ3Kn9y6gZ8RKQbKhz4uMgf5vKsoBhDwtvRi0E mSBkBxdLLdepRztQVoLIIF/Q7vUyI0GH6YNyDbUp3rRZmnJjwFOWHEueoBfZSFMGGF RqtOmYsSKefSznKC1XdVa3LwZwcre1d/3y5decb9BmbtdbyusaJNpKUISQiC91uHdg U0EOVISllV8/dun3hSuDFhzfuXhasGJ15qIvNrvLydffbKf/8TmMLA1IiNsdU5bzMF 3aUehHwVeVMkTlL6CEqWAoikiivx1WreVLaBWtbaDcVxXGlB1WUJ2ywkrp9GP3mPMT Alh73RJwu+/jA==
Message-ID: <ba509b9a-0e35-4530-a3d9-673ed0ae5c5c@dansarie.se>
Date: Tue, 02 Apr 2024 21:35:37 +0200
MIME-Version: 1.0
Content-Language: en-US
From: Marcus Dansarie <marcus@dansarie.se>
To: "ntp@ietf.org" <ntp@ietf.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/RreS82lFRzPdjCdqq46MPRlvob0>
Subject: [Ntp] Roughtime time resolution and timestamp format
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: Tue, 02 Apr 2024 19:41:42 -0000
Dear all, I looked over the latest Roughtime draft this weekend. One of the things that struck me was that the protocol's time resolution has changed three or four times in the nine drafts so far. I discussed this off-list with Watson and he suggested that we check with the list what people think is appropriate. In the current draft, resolution in both time and accuracy is one second. This means that the lowest possible interval reported by a Roughtime server will be two seconds (i.e. plus/minus one second). The midpoint can be off by as much as half a second from the server's best time estimate. The resolution in previous drafts has been microseconds. Related to this is the question of how time should be formatted in the protocol. In the current draft, time is transferred as the "count of seconds since the Unix epoch in UTC". Previous drafts have used either microseconds since the Unix epoch or modified Julian date and microseconds since midnight. Personally, I think that single-second resolution is too low. Indeed, a user could look at two devices that have successfully used Roughtime to get time and visibly see that they do not match. Also, a second is eons in computer time. At the very least, we should specify decisecond resolution and preferably millisecond. I am also hesitant towards using the Unix epoch, considering the history of problems involving conversions to and from it, not to mention leap seconds. The time transferred with Roughtime should be clear and unambiguous. For that reason, I prefer the date and time-since-midnight format. The date could be either days since an epoch or year-month-day. To summarize, these are the two questions that we would like to hear your opinions (and eventually reach consensus) on: * What resolution of time and time accuracy should Roughtime use? * What should the Roughtime timestamp format look like? Kind regards, Marcus
- Re: [Ntp] Roughtime time resolution and timestamp… Christopher Patton
- [Ntp] Roughtime time resolution and timestamp for… Marcus Dansarie
- Re: [Ntp] Roughtime time resolution and timestamp… Tal Mizrahi
- Re: [Ntp] [EXT] Roughtime time resolution and tim… Windl, Ulrich