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

On Tue, Jul 8, 2025 at 8:07 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> BTW, returning to the original topic of this thread:
>
> The new exact-delays table from pg_test_timing is really quite
> informative.

Maybe we should collect some of it in the PostgreSQL Wiki for easy reference ?

I had some interesting results with some RISC-V SBC which were similar
to ARM but
seemed to indicate that the chosen "CPU CLOCK" used by the
rtdsc-equivalent instruction was counting in exact multiples of a
nanosecond

And "the rtdsc-equivalent instruction" on both ARM and RISC-V is
reading a special register which exposes the faked "clock counter".

> For example, on my M4 Macbook:
>
> Observed timing durations up to 99.9900%:
> ns % of total running % count
> 0 62.2124 62.2124 118127987
> 41 12.5826 74.7951 23891661
> 42 25.1653 99.9604 47783489
> 83 0.0194 99.9797 36744
> 84 0.0096 99.9893 18193
> 125 0.0020 99.9913 3784
> ...
> 31042 0.0000 100.0000 1
>
> The fact that the clock tick is about 40ns is extremely
> obvious in this presentation.
>
> Even more interesting is what I got from an ancient PPC Macbook
> (mamba's host, running NetBSD):
>
> Testing timing overhead for 3 seconds.
> Per loop time including overhead: 731.26 ns
> ...
> Observed timing durations up to 99.9900%:
> ns % of total running % count
> 705 39.9162 39.9162 1637570
> 706 17.6040 57.5203 722208
> 759 18.6797 76.2000 766337
> 760 23.7851 99.9851 975787
> 813 0.0002 99.9853 9
> 814 0.0004 99.9857 17
> 868 0.0001 99.9858 4
> 922 0.0001 99.9859 3

Do we have a fencepost error in the limit code so that it stops before
printing out the 99.9900% limit row ?

The docs in your latest patch indicated that it prints out the row >= 99.9900%

---
Hannu