Re: What is a typical precision of gettimeofday()? - Mailing list pgsql-hackers
From | Hannu Krosing |
---|---|
Subject | Re: What is a typical precision of gettimeofday()? |
Date | |
Msg-id | CAMT0RQSbzeJN+nPo_QXib-P62rgez=dJxoaTURcN1FYPoLpQPg@mail.gmail.com Whole thread Raw |
In response to | Re: What is a typical precision of gettimeofday()? (Hannu Krosing <hannuk@google.com>) |
List | pgsql-hackers |
Here is the output of nanosecond-precision pg_test_timing on M1 Macbook Air /work/postgres/src/bin/pg_test_timing % ./pg_test_timing Testing timing overhead for 3 seconds. Per loop time including overhead: 21.54 ns Histogram of timing durations: <= ns % of total running % count 0 49.1655 49.1655 68481688 1 0.0000 49.1655 0 3 0.0000 49.1655 0 7 0.0000 49.1655 0 15 0.0000 49.1655 0 31 0.0000 49.1655 0 63 50.6890 99.8545 70603742 127 0.1432 99.9976 199411 255 0.0015 99.9991 2065 511 0.0001 99.9992 98 1023 0.0001 99.9993 140 2047 0.0002 99.9995 284 4095 0.0000 99.9995 50 8191 0.0000 99.9996 65 16383 0.0002 99.9997 240 32767 0.0001 99.9998 128 65535 0.0001 99.9999 97 131071 0.0000 99.9999 58 262143 0.0000 100.0000 44 524287 0.0000 100.0000 22 1048575 0.0000 100.0000 7 2097151 0.0000 100.0000 2 First 128 exact nanoseconds: 0 49.1655 49.1655 68481688 41 16.8964 66.0619 23534708 42 33.7926 99.8545 47069034 83 0.0835 99.9380 116362 84 0.0419 99.9799 58349 125 0.0177 99.9976 24700 As you see the 40 ns internal tick gets somehow blurred into not-quite-40-ns timing step On Linux / ARM Ampere where __builtin_readcyclecounter() works (it compiles but crashes on Mac OS M1, I have not yet tested on Linux M1) the tick is exactly 40 ns and I'd expect it to be the same on M1. On Tue, Jun 18, 2024 at 5:08 PM Hannu Krosing <hannuk@google.com> wrote: > > I plan to send patch to pg_test_timing in a day or two > > the underlying time precision on modern linux seems to be > > 2 ns for some Intel CPUs > 10 ns for Zen4 > 40 ns for ARM (Ampere) > > --- > Hannu > > > > | > > > > > On Tue, Jun 18, 2024 at 7:48 AM Andrey M. Borodin <x4mmm@yandex-team.ru> wrote: >> >> >> >> > On 19 Mar 2024, at 13:28, Peter Eisentraut <peter@eisentraut.org> wrote: >> > >> > I feel that we don't actually have any information about this portability concern. Does anyone know what precisionwe can expect from gettimeofday()? Can we expect the full microsecond precision usually? >> >> At PGConf.dev Hannu Krossing draw attention to pg_test_timing module. I’ve tried this module(slightly modified to measurenanoseconds) on some systems, and everywhere I found ~100ns resolution (95% of ticks fall into 64ns and 128ns buckets). >> >> I’ll add cc Hannu, and also pg_test_timing module authors Ants ang Greg. Maybe they can add some context. >> >> >> Best regards, Andrey Borodin.
pgsql-hackers by date: