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

[Ulrich Windl <[e-mail]>]

>>> Hal Murray <[e-mail]> schrieb am 01.12.2020 um 10:54 in
Nachricht <[e-mail]>:

> [e-mail]‑regensburg.de said:
>> (Say your clock has 1ns resolution, but reading it takes 10 to 15 ns,
maybe
>> even longer if there's high system load).
> 
> That 10 or 15 ns is a pipeline delay.  It's not directly related to the 
> clock 
> precision.
> 
> The typical clock on an Intel PC uses the TSC which ticks at the CPU clock 
> frequency.  If your CPU is running at more than 1 GHz, then the clock will 
> be 
> good to better than 1 ns.

Hi Hal!

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.

> 
> 
> Here is a histogram of how long it takes to read the clock on a Raspberry 
> Pi.
> (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.
> 
> 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
100ns most of the time, does it make any difference whether the clock's
precision is 1 or 5ns?

Regards,
Ulrich


> 
> You can read a clock that ticks slowly with (much) more precision that its 
> nominal period.  The classic example is the TOY/CMOS battery backed clock 
> that 
> only ticks once a second.  If you spin until it ticks, you can get much 
> closer 
> than 1 second.  "Spin until" may not be convenient for most applications.
> 
> 
> ‑‑ 
> These are my opinions.  I hate spam.