New toy: attic/clocks.c - time sink warning

Gary E. Miller gem at rellim.com
Tue Jan 8 22:27:42 UTC 2019


Yo Hal!

On Tue, 08 Jan 2019 04:06:57 -0800
Hal Murray via devel <devel at ntpsec.org> wrote:

> It gets built by default, so all you have to do is run
>   ./build/main/attic/clocks

I have been thinking in a similar vein.  When my PPS is more accurate
than the granularity of the system clock odd things are happening.

Also idd that the results are so different for clocks than in gpsd with
the clock_test program.

All the hosts below have the CPU governor set to performance.

For example, on an E3-1245 v3 @ 3.40GHz:

# ./clocks 
      res   avg     min  dups  CLOCK
        1    15      11        CLOCK_REALTIME
 10000000     4 999999999     0  CLOCK_REALTIME_COARSE
        1    15      11        CLOCK_MONOTONIC
        1   204     192        CLOCK_MONOTONIC_RAW
        1   206     200        CLOCK_BOOTTIME

Histogram: CLOCK_REALTIME, 5 ns per bucket, 1000000 samples.
        ns      hits
        11    713555
        16    286093
        21       314
        26        18
        31         4
16 samples were bigger than 36.

# ./clock_test 
samples 101, delay 10000000 ns
min 51 ns, max 74 ns, mean 53 ns, median 52 ns, StdDev 3 ns

clocks seems to show a clock granularity of 11 ns, but clock_test shows 51 ns.

On an E5-1620 v3 @ 3.50GHz

 # ./clocks
      res   avg     min  dups  CLOCK
        1    23      16        CLOCK_REALTIME
  3333333     9 3333330    -2  CLOCK_REALTIME_COARSE
        1    22      16        CLOCK_MONOTONIC
        1   301     214        CLOCK_MONOTONIC_RAW
        1   311     214        CLOCK_BOOTTIME

Histogram: CLOCK_REALTIME, 5 ns per bucket, 1000000 samples.
        ns      hits
        16     10746
        21      3894
        26       246
        31         2
        36         2
        46         1
        56        13
        66         1
        76         1
        81         3
        91         3
        96         1
       101         1
       121         1
       126         5
       131         1
       136         1
       141         2
       151         1
       156         2
       186         1
       351         1
985071 samples were bigger than 1266.

# ./clock_test
samples 101, delay 10000000 ns
min 24 ns, max 297 ns, mean 53 ns, median 48 ns, StdDev 34 ns

clocks shows a granularity of 16 ns, but clock_test shows 24 ns.

And on a RasPi 3B whith 32 bit kernel:

# ./clock 
      res   avg     min  dups  CLOCK
        1   301     260        CLOCK_REALTIME
  1000000   182  999993  -158  CLOCK_REALTIME_COARSE
        1   289     260        CLOCK_MONOTONIC
        1  1035     989        CLOCK_MONOTONIC_RAW
        1  1442    1354        CLOCK_BOOTTIME

Histogram: CLOCK_REALTIME, 5 ns per bucket, 1000000 samples.
        ns      hits
       260    492820
       310    506652
       360        30
       365        51
       415        66
381 samples were bigger than 420.

# ./clock_test
samples 101, delay 10000000 ns
min 260 ns, max 989 ns, mean 353 ns, median 364 ns, StdDev 71 ns

And here the two tests seem to agree...

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20190108/db531a60/attachment.bin>


More information about the devel mailing list