Re: [Ntp] Antw: Re: Antw: [EXT] Minutes from IETF 108 NTP WG session
Miroslav Lichvar <mlichvar@redhat.com> Mon, 03 August 2020 13:11 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 55BE83A091C for <ntp@ietfa.amsl.com>; Mon, 3 Aug 2020 06:11:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.201
X-Spam-Level:
X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 PbaiRDSFyvgD for <ntp@ietfa.amsl.com>; Mon, 3 Aug 2020 06:11:08 -0700 (PDT)
Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 466103A0918 for <ntp@ietf.org>; Mon, 3 Aug 2020 06:11:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1596460267; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Rns1AnC75Rx7A52eTWxtJO/j1MnOcFIRzPyWaNAeo2E=; b=LsU6vXdJ+9bGNsW1/I0dwulAFstuFv5a/WBbTTyhOPGDzJvAB8hAtNMjtfb8KJfsUU5Pea eGE/YDmt6mHH11DZlchC1xDxs/J/fG4qffBZJOGTSHoVyVq/PMR3j2h7mgAv+OXiehFX6I eSTNsWIML7K6fAIk5T2GhAoHeXLiaME=
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-286-SbenfxLRO8OCqeJiaR9vXA-1; Mon, 03 Aug 2020 09:11:05 -0400
X-MC-Unique: SbenfxLRO8OCqeJiaR9vXA-1
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A546C10059BB for <ntp@ietf.org>; Mon, 3 Aug 2020 13:11:04 +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 2CB2A87E3C for <ntp@ietf.org>; Mon, 3 Aug 2020 13:11:03 +0000 (UTC)
Date: Mon, 03 Aug 2020 15:11:02 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: ntp@ietf.org
Message-ID: <20200803131102.GM762467@localhost>
References: <mlichvar@redhat.com> <20200803112130.GL762467@localhost> <20200803121241.CDFFC406074@ip-64-139-1-69.sjc.megapath.net>
MIME-Version: 1.0
In-Reply-To: <20200803121241.CDFFC406074@ip-64-139-1-69.sjc.megapath.net>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/8t0qU0-H1sJlMd1FvP668IyshlM>
Subject: Re: [Ntp] Antw: Re: Antw: [EXT] Minutes from IETF 108 NTP WG session
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: Mon, 03 Aug 2020 13:11:09 -0000
On Mon, Aug 03, 2020 at 05:12:41AM -0700, Hal Murray wrote: > >> (D)get_res: smallest delta is 0.000001514 > >> (D)get_res: largest delta is 0.000001695 > > > This suggests the system is not using the TSC clocksource, but something > > slower like HPET. Check the following files: > > Maybe, but I'll bet a bigger contribution is doing a syscall rather than using > vsdo. That depends on hardware and kernel configuration. Looking at some of my old tests, the overhead of the syscall was much smaller then reading of the HPET itself. However, on Intel CPUs some of the security mitigations (KPTI) made the syscall about 3x slower, so I guess it could be now comparable or even larger than the HPET reading. -- Miroslav Lichvar
- [Ntp] Minutes from IETF 108 NTP WG session Dieter Sibold
- [Ntp] Antw: [EXT] Minutes from IETF 108 NTP WG se… Ulrich Windl
- Re: [Ntp] Antw: [EXT] Minutes from IETF 108 NTP W… Miroslav Lichvar
- [Ntp] Antw: Re: Antw: [EXT] Minutes from IETF 108… Ulrich Windl
- Re: [Ntp] Antw: Re: Antw: [EXT] Minutes from IETF… Miroslav Lichvar
- Re: [Ntp] Antw: Re: Antw: [EXT] Minutes from IETF… Hal Murray
- Re: [Ntp] Antw: Re: Antw: [EXT] Minutes from IETF… Hal Murray
- Re: [Ntp] Antw: Re: Antw: [EXT] Minutes from IETF… Miroslav Lichvar