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