From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Hannu Krosing <hannuk(at)google(dot)com> |
Cc: | "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>, Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: What is a typical precision of gettimeofday()? |
Date: | 2025-07-08 18:07:55 |
Message-ID: | 891253.1751998075@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
BTW, returning to the original topic of this thread:
The new exact-delays table from pg_test_timing is really quite
informative. 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
...
564950 0.0000 100.0000 1
I had previously reported that that machine had microsecond
timing precision, but this shows that the real problem is that
it takes most of a microsecond to go 'round the timing loop.
It seems clear that the system clock ticks about every 50ns,
even on this decades-old hardware.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrey Borodin | 2025-07-08 18:25:44 | Re: What is a typical precision of gettimeofday()? |
Previous Message | Dean Rasheed | 2025-07-08 17:43:58 | Re: Remove redundant comment regarding RelationBuildRowSecurity in relcache.c |