Re: What is a typical precision of gettimeofday()? - Mailing list pgsql-hackers

Hannu Krosing <hannuk@google.com> writes:
> On Tue, Jul 8, 2025 at 8:07 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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 ?

No, I think what's happening there is that we get to NUM_DIRECT before
reaching the 99.99% mark.  Running the test a bit longer, I do get a
hit at the next plausible 50ns step:

$ ./pg_test_timing -d 10
Testing timing overhead for 10 seconds.
Per loop time including overhead: 729.79 ns
Histogram of timing durations:
   <= ns   % of total  running %      count
       0       0.0000     0.0000          0
       1       0.0000     0.0000          0
       3       0.0000     0.0000          0
       7       0.0000     0.0000          0
      15       0.0000     0.0000          0
      31       0.0000     0.0000          0
      63       0.0000     0.0000          0
     127       0.0000     0.0000          0
     255       0.0000     0.0000          0
     511       0.0000     0.0000          0
    1023      99.9879    99.9879   13700887
    2047       0.0000    99.9880          2
    4095       0.0063    99.9942        859
    8191       0.0019    99.9962        267
   16383       0.0017    99.9978        227
   32767       0.0012    99.9990        166
   65535       0.0001    99.9992         16
  131071       0.0007    99.9998         90
  262143       0.0000    99.9998          5
  524287       0.0001    99.9999         11
 1048575       0.0001   100.0000         10

Observed timing durations up to 99.9900%:
      ns   % of total  running %      count
     705      40.7623    40.7623    5585475
     706      17.9732    58.7355    2462787
     759      18.1392    76.8747    2485525
     760      23.1129    99.9876    3167060
     813       0.0000    99.9877          5
     814       0.0002    99.9878         23
     868       0.0000    99.9879          5
     869       0.0000    99.9879          1
     922       0.0000    99.9879          3
     923       0.0000    99.9879          2
     976       0.0000    99.9879          1
...
  625444       0.0000   100.0000          1

amd the next step after that would be 1026 ns which is past
the NUM_DIRECT array size.

I considered raising NUM_DIRECT some more, but I think it'd be
overkill.  This machine is surely an order of magnitude slower
than anything anyone would consider of practical interest today.
Just for fun, though, I tried a run with NUM_DIRECT = 10240:

$ ./pg_test_timing -d 10
Testing timing overhead for 10 seconds.
Per loop time including overhead: 729.23 ns
Histogram of timing durations:
   <= ns   % of total  running %      count
       0       0.0000     0.0000          0
       1       0.0000     0.0000          0
       3       0.0000     0.0000          0
       7       0.0000     0.0000          0
      15       0.0000     0.0000          0
      31       0.0000     0.0000          0
      63       0.0000     0.0000          0
     127       0.0000     0.0000          0
     255       0.0000     0.0000          0
     511       0.0000     0.0000          0
    1023      99.9878    99.9878   13711494
    2047       0.0000    99.9878          5
    4095       0.0062    99.9941        854
    8191       0.0021    99.9962        289
   16383       0.0017    99.9979        236
   32767       0.0011    99.9990        153
   65535       0.0002    99.9992         24
  131071       0.0006    99.9998         85
  262143       0.0001    99.9999          8
  524287       0.0001    99.9999          9
 1048575       0.0001   100.0000          7
 2097151       0.0000   100.0000          0
 4194303       0.0000   100.0000          0
 8388607       0.0000   100.0000          0
16777215       0.0000   100.0000          0
33554431       0.0000   100.0000          1
67108863       0.0000   100.0000          1

Observed timing durations up to 99.9900%:
      ns   % of total  running %      count
     705      50.3534    50.3534    6905051
     706      22.1988    72.5522    3044153
     759      12.0613    84.6135    1653990
     760      15.3732    99.9867    2108150
     813       0.0000    99.9867          2
     814       0.0002    99.9869         27
     868       0.0006    99.9875         85
     869       0.0000    99.9876          2
     922       0.0001    99.9877         20
     923       0.0001    99.9878          9
     976       0.0000    99.9878          2
     977       0.0000    99.9878          3
    1031       0.0000    99.9878          4
    1248       0.0000    99.9878          1
    2550       0.0002    99.9880         26
    2604       0.0008    99.9889        114
    2605       0.0002    99.9891         30
    2658       0.0005    99.9896         75
    2659       0.0004    99.9901         61
...
65362171       0.0000   100.0000          1

This is probably showing something interesting about the
behavior of NetBSD's scheduler, but I dunno what exactly.

            regards, tom lane