rate: extend maximum-delay slop to all platforms
I initially added some timing slop for specific platforms based on the
failures we had seen so far (and a theory explaining at least some of
those failures). But now we've seen overruns on other platforms too,
so perhaps we should use the same factors everywhere.
Fixes #43055 (I hope).
Change-Id: Ib6035b55acd9d17acc7ad78065abf5f1e3f9dfe7
Reviewed-on: https://go-review.googlesource.com/c/time/+/399535
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
diff --git a/rate/rate_test.go b/rate/rate_test.go
index 57dd1a7..5d5fabf 100644
--- a/rate/rate_test.go
+++ b/rate/rate_test.go
@@ -434,19 +434,19 @@
// The actual time spend waiting will be INCREASED by the amount of scheduling
// slop in the platform's sleep syscall, plus the amount of time spent executing
// straight-line code before measuring the elapsed duration.
- // (The latter is surely less than half a d.)
- maxD := wantD
- switch runtime.GOOS {
- case "netbsd", "openbsd", "android", "plan9":
- // NetBSD and OpenBSD tend to overshoot sleeps by a wide margin due to a
- // suspected platform bug; see https://go.dev/issue/44067 and
- // https://go.dev/issue/50189.
- //
- // Android and plan9 were empirically observed to overshoot too.
- // Android might be trying to conserve power.
- // For plan9, I (bcmills) am not sure what the problem would be.
- maxD = (wantD*3 + 1) / 2 // 150% of wantD, rounded up.
- }
+ //
+ // The latter is surely less than half a d, but the former is empirically
+ // sometimes larger on a number of platforms for a number of reasons.
+ // NetBSD and OpenBSD tend to overshoot sleeps by a wide margin due to a
+ // suspected platform bug; see https://go.dev/issue/44067 and
+ // https://go.dev/issue/50189.
+ // Longer delays were also also observed on slower builders with Linux kernels
+ // (linux-ppc64le-buildlet, android-amd64-emu), and on Solaris and Plan 9.
+ //
+ // Since d is already fairly generous, we take 150% of wantD rounded up —
+ // that's at least enough to account for the overruns we've seen so far in
+ // practice.
+ maxD := (wantD*3 + 1) / 2
return gotD <= maxD
}
