Re: [Ntp] Antw: Re: Antw: Re: Antw: [EXT] Re: NTPv5 draft

Hal Murray <hmurray@megapathdsl.net> Tue, 01 December 2020 13:49 UTC

Return-Path: <hmurray@megapathdsl.net>
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 182183A123E for <ntp@ietfa.amsl.com>; Tue, 1 Dec 2020 05:49:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.037
X-Spam-Level: *
X-Spam-Status: No, score=1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_DYNAMIC_IPADDR=1.951, PDS_RDNS_DYNAMIC_FP=0.001, RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 yuUfvHngGSdu for <ntp@ietfa.amsl.com>; Tue, 1 Dec 2020 05:49:04 -0800 (PST)
Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by ietfa.amsl.com (Postfix) with ESMTP id C15DD3A123D for <ntp@ietf.org>; Tue, 1 Dec 2020 05:49:04 -0800 (PST)
Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id ED75B40605C; Tue, 1 Dec 2020 05:49:03 -0800 (PST)
X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3
To: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
cc: Hal Murray <hmurray@megapathdsl.net>, "ntp@ietf.org" <ntp@ietf.org>
From: Hal Murray <hmurray@megapathdsl.net>
In-Reply-To: Message from "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> of "Tue, 01 Dec 2020 13:19:16 +0100." <5FC634C4020000A10003D339@gwsmtp.uni-regensburg.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 01 Dec 2020 05:49:03 -0800
Message-Id: <20201201134903.ED75B40605C@ip-64-139-1-69.sjc.megapath.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/ioYKtpj_Q_HRPp1J4F3WxbmMP78>
Subject: Re: [Ntp] Antw: Re: Antw: Re: Antw: [EXT] Re: NTPv5 draft
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: Tue, 01 Dec 2020 13:49:06 -0000

Ulrich.Windl@rz.uni-regensburg.de said:
> Is that pure theory, or actual measurements? I mean you'll have to do either
> memory-mapped I/O which won't be cached (hopefully), or you'll have to read I/
> O ports. Or do you talk about something inside the CPU? If so that may have
> high precision until the CPU goes to power saving or whatever. 

Intel has an instruction, rdtsc, that reads the TSC register.  It counts 
cycles.  Early implementations had problems since it counted CPU cycles rather 
than counting at a constant rate.  Those have all been sorted out.  It takes a 
long time to read it.  I don't know the details of what happens on SMP systems.
  https://en.wikipedia.org/wiki/Time_Stamp_Counter

There is some shared memory.  vdso is the buzzword.  There is a man page.

If the shared memory has a time stamp, and a TSC reading for that time, and a 
scale factor that turns TSC ticks into nanoseconds, you can compute the time as
  (newTSC-oldTSC)*scale + base_time.
There is some interesting hacking required to maintain precision and avoid 
overflow and such.  (And more hacking to avoid a race condition when things 
get updated.)

The similar instruction on ARM is illegal in user mode unless you turn on a 
magic bit.  I have no idea why.  Maybe some kernel option turns it on by now.  
Or maybe it was MIPS.  ????

----------

>> So the clock is ticking at somewhere between 2 and 53 ns.
> Where did you get that 2 from? Assuming your read delay is between 50 and

Typo.  It should be 52

> (Raspberry Pi 3 Model B running Fedora aarch64)
>         ns      hits
>         52    497520
>         53     45070
>        104    381437
>        105     75962
>        156         4
> 7 samples were bigger than 2551.

That clock steps by 52-53.  There are no hits between o-53 and 53-104 and 
105-156.

On an Intel, I see this histogram:
(i3-2120 CPU @ 3.30GHz)
        ns      hits
        19    489605
        20    412237
        21     62486
        22     35190
        23        63
        24        50
        25        55
        26        50
        27        57
        28        56


-- 
These are my opinions.  I hate spam.