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 }