[Ntp] Antw: Re: Antw: [EXT] Minutes from IETF 108 NTP WG session

[Ulrich Windl <[e-mail]>]

>>> Miroslav Lichvar <[e-mail]> schrieb am 03.08.2020 um 12:36 in
Nachricht <20200803103618.GK762467@localhost>:
> On Mon, Aug 03, 2020 at 08:17:08AM +0200, Ulrich Windl wrote:
>> "It turns out that for trades a nanosecond resolution matters."
>> 
>> I wonder what's really behind that claim: Reading the current system time
on 
> a
>> current Linux server yields in about 1µs precision (independent from how 
> the
>> clock is synchronized).
> 
> On modern computers running Linux, at least for the last decade, the
> time it takes to read the system clock is usually less than 50
> nanoseconds. I have not seen a sub‑10ns clock yet. That's still an

Hi!

I'm surprised.

I wrote an algorithm like this to "measure":

typedef struct timespec ts_t;           /* short-cut for struct timespec */
static  long    get_res(ts_t *tsp)
{
        int             result;
        ts_t            samples[CLOCK_SAMPLES];
        unsigned        u;

        if ( (result = clock_getres(CLOCK_MONOTONIC, tsp)) != 0 )
                goto leave;
        assert(tsp->tv_sec == 0);
        for ( u = 0; u < CLOCK_SAMPLES; ++u )
        {
                get_time(samples + u);
        }
        for ( u = 1; u < CLOCK_SAMPLES; ++u )
        {
                samples[u - 1] = subtract_time(&samples[u], &samples[u - 1]);
        }
        qsort(samples, CLOCK_SAMPLES - 1, sizeof(samples[0]), cmp_time);
        if ( samples[0].tv_nsec > tsp->tv_nsec )
                tsp->tv_nsec = samples[0].tv_nsec;
leave:  return(result);
}

On one machine I got these debugging messages:
(D)get_res: resolution is 0.000000001 ## from POSIX call
(D)get_res: smallest delta is 0.000001514
(D)get_res: largest delta is 0.000001695
(I)set_resolution: ts 0.000001514, digits 6, nsecs 1000

So your machines must be way faster... OK, I tried the latest generation we
have:
(D)get_res: resolution is 0.000000001
(D)get_res: smallest delta is 0.000000030
(D)get_res: largest delta is 0.000000100
(D)set_resolution: ts 0.000000030, digits 8, nsecs 10

> order of magnitude to get into the sub‑nanosecond range. Even if the
> CPU was so fast that it could read and convert the TSC counter in less
> than a nanosecond, there is no POSIX API to return the timestamp in a
> sub‑nanosecond resolution.
> 
> I guess for hardware clocks (e.g. NICs that support hardware
> timestamping) a sub‑nanosecond resolution might be needed sooner than
> for the system clock.
> 
> NTP has a 1/4ns resolution. For the White Rabbit that might not be
> good enough. For synchronizing ordinary computers (in financial
> industry or other) I think that will be sufficient for quite some
> time. In any case, a correction extension field (which will need to be
> supported in switches/routers in order to get a sub‑nanosecond
> accuracy) can have a better resolution than the timestamps in the NTP
> header.
> 
>> So before claiming that financial industry needs sub‑nanosecond
resolution,
>> I'd like to see hard facts and details.
> 
> FWIW, I have not heard anyone asking for a sub‑nanosecond resolution
> yet. The accuracy of the clock is a bigger issue.
> 
>> The other thing is: How small would the stability of the clock have to be
to
>> make any sub‑nanosecond resolution be realistic? 0.001 PPM?
>> Real "normal" servers will probably have 1 PPM, and a "certified 
> chronograph"
>> will allow around 50 PPM (AFAIK)...
> 
> For sub‑nanosecond stability with an ordinary computer clock, the
> update interval would need to very short, e.g. few milliseconds.
> 
> In a test I did with two directly connected idle computers and a
> polling interval of ‑6 (using the interleaved mode), the reported
> stability was just a few nanoseconds. With a shorter interval it might
> be possible to get it under 1 nanosecond, but I'm not sure what would
> be the point when the precision and accuracy of the clock is in tens
> nanoseconds at best.

My guess is that your oscillator was much better than standard, TCXO and OCXO,
or you have a very stable temperature around.

Regards,
Ulrich