Re: What is a typical precision of gettimeofday()?

(resending to list and other CC:s )

Hi Tom

This is my current patch which also adds running % and optionally uses
faster way to count leading zeros, though I did not see a change from
that.

It also bucketizes first 128 ns to get better overview of exact behaviour.

We may want to put reporting this behind a flag

---
Hannu

On Wed, Jun 19, 2024 at 6:36 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Peter Eisentraut <peter(at)eisentraut(dot)org> writes:
> > AFAICT, pg_test_timing doesn't use gettimeofday(), so this doesn't
> > really address the original question.
>
> It's not exactly hard to make it do so (see attached).
>
> I tried this on several different machines, and my conclusion is that
> gettimeofday() reports full microsecond precision on any platform
> anybody is likely to be running PG on today. Even my one surviving
> pet dinosaur, NetBSD 10 on PowerPC Mac (mamba), shows results like
> this:
>
> $ ./pg_test_timing
> Testing timing overhead for 3 seconds.
> Per loop time including overhead: 901.41 ns
> Histogram of timing durations:
> < us % of total count
> 1 10.46074 348148
> 2 89.51495 2979181
> 4 0.00574 191
> 8 0.00430 143
> 16 0.00691 230
> 32 0.00376 125
> 64 0.00012 4
> 128 0.00303 101
> 256 0.00027 9
> 512 0.00009 3
> 1024 0.00009 3
>
> I also modified pg_test_timing to measure nanoseconds not
> microseconds (second patch attached), and got this:
>
> $ ./pg_test_timing
> Testing timing overhead for 3 seconds.
> Per loop time including overhead: 805.50 ns
> Histogram of timing durations:
> < ns % of total count
> 1 19.84234 739008
> 2 0.00000 0
> 4 0.00000 0
> 8 0.00000 0
> 16 0.00000 0
> 32 0.00000 0
> 64 0.00000 0
> 128 0.00000 0
> 256 0.00000 0
> 512 0.00000 0
> 1024 80.14013 2984739
> 2048 0.00078 29
> 4096 0.00658 245
> 8192 0.00290 108
> 16384 0.00252 94
> 32768 0.00250 93
> 65536 0.00016 6
> 131072 0.00185 69
> 262144 0.00008 3
> 524288 0.00008 3
> 1048576 0.00008 3
>
> confirming that when the result changes it generally does so by 1usec.
>
> Applying just the second patch, I find that clock_gettime on this
> old hardware seems to be limited to 1us resolution, but on my more
> modern machines (mac M1, x86_64) it can tick at 40ns or less.
> Even a raspberry pi 4 shows
>
> $ ./pg_test_timing
> Testing timing overhead for 3 seconds.
> Per loop time including overhead: 69.12 ns
> Histogram of timing durations:
> < ns % of total count
> 1 0.00000 0
> 2 0.00000 0
> 4 0.00000 0
> 8 0.00000 0
> 16 0.00000 0
> 32 0.00000 0
> 64 37.59583 16317040
> 128 62.38568 27076131
> 256 0.01674 7265
> 512 0.00002 8
> 1024 0.00000 0
> 2048 0.00000 0
> 4096 0.00153 662
> 8192 0.00019 83
> 16384 0.00001 3
> 32768 0.00001 5
>
> suggesting that the clock_gettime resolution is better than 64 ns.
>
> So I concur with Hannu that it's time to adjust pg_test_timing to
> resolve nanoseconds not microseconds. I gather he's created a
> patch that does more than mine below, so I'll wait for that.
>
> regards, tom lane
>