Michael Banck <mba...@gmx.net> writes: > On Wed, Sep 24, 2025 at 05:52:02PM +0200, Michael Banck wrote: >> I did that in the attached, so far my Hurd VM ran the stats test more >> than 1000 times without a failure with it. I have the loop running till >> 10000, I'll report back tomorrow.
> For the record, the stats test ran 10000 times without a failure with > that patch applied. Okay. Elsewhere on the playing field, 32 buildfarm animals have now reported in with full pg_test_timing output. (I'd thought we might get more, but apparently there's still only a minority of animals configured with --enable-tap-tests.) Here's the URLs for those runs, along with my notes about what the results look like: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=alligator&dt=2025-09-25%2014%3A02%3A34 Ubuntu/x86_64: timing seems to be ns-precise https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=basilisk&dt=2025-09-25%2011%3A01%3A29 Alpine Linux/x86_64: looks to have 10ns ticks https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=batta&dt=2025-09-25%2014%3A05%3A01 Debian/aarch64: looks to have 10ns ticks https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=billbug&dt=2025-09-25%2003%3A00%3A03 Solaris/sparc: looks to have 15ns ticks https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bumblebee&dt=2025-09-25%2015%3A00%3A02 CentOS/x86_64: looks to have 10ns ticks https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bushmaster&dt=2025-09-25%2013%3A40%3A21 Debian/x86_64: looks to have 10ns ticks https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=canebrake&dt=2025-09-24%2019%3A14%3A48 Debian/x86_64: looks to have 10ns ticks https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=copperhead&dt=2025-09-24%2018%3A49%3A47 Debian/riscv64: looks to have 1000ns ticks https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dikkop&dt=2025-09-24%2018%3A05%3A01 FreeBSD/arm64: possibly 20ns ticks, or very noisy 10ns https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=gokiburi&dt=2025-09-25%2000%3A05%3A05 Debian/aarch64: looks to have 10ns ticks https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=grison&dt=2025-09-24%2022%3A39%3A25 Raspbian/armv7: looks to have 50ns ticks https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hachi&dt=2025-09-24%2021%3A05%3A05 Debian/aarch64: looks to have 10ns ticks https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hippopotamus&dt=2025-09-25%2013%3A35%3A48 openSUSE/x86_64: timing seems to be ns-precise https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=indri&dt=2025-09-25%2014%3A34%3A22 macOS/arm64: looks to have 40ns ticks https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jay&dt=2025-09-24%2016%3A47%3A05 openSUSE/x86_64: timing seems to be ns-precise https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=loach&dt=2025-09-25%2014%3A53%3A05 FreeBSD/x86_64: odd behavior, but I bet it's really 10ns resolution https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=longfin&dt=2025-09-25%2013%3A35%3A50 macOS/x86_64: timing seems to be ns-precise https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mamba&dt=2025-09-25%2003%3A39%3A01 NetBSD/macppc: looks to have 50ns ticks https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=margay&dt=2025-09-25%2004%3A00%3A02 Solaris/sparc: looks to have 15ns ticks https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=morepork&dt=2025-09-24%2017%3A04%3A38 OpenBSD/x86_64: horrible loop time (> 4us), but perhaps 15ns resolution underneath? https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mule&dt=2025-09-24%2019%3A30%3A01 Debian/x86_64: timing seems to be ns-precise https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=pollock&dt=2025-09-25%2005%3A35%3A13 illumos/x86_64: timing seems to be ns-precise https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prion&dt=2025-09-25%2012%3A43%3A07 Amazon Linux/86_64: timing seems to be ns-precise https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=schnauzer&dt=2025-09-24%2016%3A49%3A23 OpenBSD/x86_64: horrible loop time (> 4us), but perhaps 15ns resolution underneath? https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sidewinder&dt=2025-09-24%2018%3A35%3A01 NetBSD/x86_64: horrible loop time (> 4us), but perhaps 15ns resolution underneath? https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sifaka&dt=2025-09-25%2013%3A56%3A16 macOS/arm64: looks to have 40ns ticks https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skimmer&dt=2025-09-25%2014%3A20%3A54 CentOS/x86_64: looks to have 10ns ticks https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=snakefly&dt=2025-09-25%2013%3A32%3A08 Amazon Linux/aarch64: looks to have 10ns ticks https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=taipan&dt=2025-09-25%2013%3A51%3A19 Debian/x86_64: looks to have 10ns ticks https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=turaco&dt=2025-09-24%2018%3A15%3A03 Debian/armv7: 500ns loop time, but looks to have 15ns ticks https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=urutu&dt=2025-09-25%2012%3A55%3A44 Debian/x86_64: looks to have 10ns ticks https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=widowbird&dt=2025-09-24%2016%3A54%3A03 Debian/aarch64: looks to have 20ns ticks? So your Hurd setup seems to be in the same camp as some of the BSDen: very slow to read the clock, but the underlying hardware resolution is not bad, perhaps 10ns. Given that, I don't quite understand how it's sometimes able to report the same reading twice, but nonetheless that's what it's doing. In any case, given these results, it's really hard to credit that there are any platforms out there today that would fail to distinguish clock readings more than a couple microseconds apart. (This squares with conclusions we arrived at previously when messing about with our clock code.) So I'm inclined to set the delay in stats.spec to 10us not 1ms, just to not slow the test more than we have to. Now, pg_sleep relies on WaitLatch which has a sleep resolution of 1ms, so you might think there's little point in asking for less. But experimentation shows that if you ask for 1ms you actually get a 2ms delay --- something odd about the float roundoff behavior in pg_sleep, seems like. I think we can set the delay to less so that doesn't happen, and to be prepared in case someday the sleep resolution gets better. In short, your patch looks good and I'll go apply it with a slightly smaller delay parameter. regards, tom lane
