2021-02-20T03:31:41-f8bda1e/android-386-emu
2021-02-20T03:31:41-f8bda1e/plan9-arm

greplogs --dashboard -md -l -e 'FAIL: .*\n rate_test\.go:\d+: ' --since=2021-02-21

2022-02-03T20:56:11-f0f3c7e-355915b/android-amd64-emu
2022-01-10T22:48:57-f0f3c7e-91edf2b/openbsd-amd64-68
2022-01-04T21:10:15-f0f3c7e-1c8f9d2/android-386-emu
2021-12-07T21:54:30-f0f3c7e-cf1ec17/android-amd64-emu
2021-12-07T18:58:57-f0f3c7e-4300f10/netbsd-amd64-9_0-n1
2021-11-06T13:10:06-1f47c86-4f083c7/openbsd-amd64-68
2021-11-04T17:07:48-1f47c86-5772877/netbsd-386-9_0
2021-07-20T20:23:41-38a9dc6-9e26569/plan9-arm
2021-06-10T12:41:37-ed9ce3a-dc00dc6/android-386-emu

I think I see two mostly-independent causes here.

One is that the timing slop on NetBSD and OpenBSD is much larger than the test expects (see #50189). I suspect that is also the problem on plan9-arm.

The android failures always seem to be for Wait calls later in the sequence (act-later, which is the fourth call in its test; and will-cancel, which is the second). I suspect that the builder is slow enough — or its clock is adjusted frequently enough — that it is losing a little bit of time in between calls, and the lost time is occasionally enough to push it over a d tick into the next-lower bucket of ticks.

Indeed, I can get TestWaitSimple to fail on the first try by injecting a time.Sleep(5 * time.Millisecond) just before runWait(… "act-later" …), and I can get TestWaitCancel to fail by injecting a time.Sleep(5 * time.Millisecond) just before runWait(… "will-cancel" …).

Change https://golang.org/cl/383175 mentions this issue: rate: allow for more timing slop in TestWaitSimple