Re: [Ntp] Antw: [EXT] Re: Timescales

Miroslav Lichvar <mlichvar@redhat.com> Wed, 09 December 2020 14:22 UTC

Return-Path: <mlichvar@redhat.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 92FDB3A1690 for <ntp@ietfa.amsl.com>; Wed, 9 Dec 2020 06:22:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.121
X-Spam-Level:
X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.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 V4pKe3CxG9CR for <ntp@ietfa.amsl.com>; Wed, 9 Dec 2020 06:22:48 -0800 (PST)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8ECF3A169C for <ntp@ietf.org>; Wed, 9 Dec 2020 06:22:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1607523767; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yRHwubt4Jl5cY7mHMjxBoYugPH2U2yd3Uox6bWXGj3M=; b=Fr/CzREQSIKYlMEoOWfRyq/UIVoKi88l+coEWDtxdV4ye7hjDJ+Egrw0EZyEiMeTVjy17j qdkCuZIzjuYw2d/5kGbcpE2X5zeJd2ggmMkD1OX2yihq/xeZMWMYXddQiH4WxGQqgsvGIp rO1PLPd7uErrQ5UfnNToHcKS1VsgajM=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-373-q6t4NsOzPielUjrTtS977g-1; Wed, 09 Dec 2020 09:22:44 -0500
X-MC-Unique: q6t4NsOzPielUjrTtS977g-1
Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id EDEA4100729E for <ntp@ietf.org>; Wed, 9 Dec 2020 14:22:09 +0000 (UTC)
Received: from localhost (holly.tpb.lab.eng.brq.redhat.com [10.43.134.11]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6409E6F987 for <ntp@ietf.org>; Wed, 9 Dec 2020 14:22:07 +0000 (UTC)
Date: Wed, 09 Dec 2020 15:22:05 +0100
From: Miroslav Lichvar <mlichvar@redhat.com>
To: ntp@ietf.org
Message-ID: <20201209142205.GD2352378@localhost>
References: <20201209101830.7CB0240605C@ip-64-139-1-69.sjc.megapath.net> <20201209113003.GA2352378@localhost> <5FD0D13C020000A10003D6CB@gwsmtp.uni-regensburg.de> <20201209134612.GC2352378@localhost> <f85591b1-5d4f-d468-1011-bbeb276ebdec@thalesgroup.com>
MIME-Version: 1.0
In-Reply-To: <f85591b1-5d4f-d468-1011-bbeb276ebdec@thalesgroup.com>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13
Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=mlichvar@redhat.com
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/wWV1vcVKs9kLG1qXp65HSPHoIDI>
Subject: Re: [Ntp] Antw: [EXT] Re: Timescales
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: Wed, 09 Dec 2020 14:22:50 -0000

On Wed, Dec 09, 2020 at 02:07:28PM +0000, FUSTE Emmanuel wrote:
> Le 09/12/2020 à 14:46, Miroslav Lichvar a écrit :
> > NTP could distribute a leap-second table (it already did it with
> > Autokey, right?), but isn't NTP about distributing current time,
> > rather than reconstructing time in the past or future?
> >
> "Current" is a referential problem. As soon as you distribute/tackle 
> different time scale which one is "current" ?
> You will more or less  inevitably start to need to reconstruct time in 
> the past or future.

In all timescales there should be a value corresponding to current
time. It may be ambiguous.

For the purposes of clock synchronization I think the client just
needs to know the current time and whether there will be a leap second
in the next slot if the timescale jumps on the leap second. If NTP
should also allow the client to know current time in another
timescale, it also needs to know the current offset (e.g. relative to
the receive timestamp) between those two timescales. The NTPv5 draft
does that.

Most computers work primarily in UTC. The leap second tables are not
universally available. NTP needs to keep the UTC support and work even
when the TAI-UTC offset is unknown.

-- 
Miroslav Lichvar