(Found while looking at subrepos for #11811)

I'll look later on an actual OpenBSD machine, but my suspicion is it's probably something to do with the time.Sleep(2 * time.Millisecond) call and OpenBSD's scheduler only having 10ms granularity.

Can you add a t.Skip or something at least? (if there's not a better way to actually fix or fix the test)

If that's the only solution I can come up with, sure.

The problem seems to be that time.Sleep on OpenBSD is oversleeping. It's rounding the sleep duration up to the nearest 10ms multiple (which at least makes sense due to OpenBSD's 10ms scheduler clock interval), but then it's also always sleeping an additional 10ms.

For example, TestLongRunningQPS's time.Sleep(2 * time.Millisecond) call is actually sleeping for 20ms on average (rounded up to 10ms, then plus an additional 10ms). This limits the test to 50 attempts per second; below the 100 attempts per second rate limit the test is using.

The test can be made to work on OpenBSD by lowering the rate to below 50/s, but I think for now it makes sense to just skip it on OpenBSD while I investigate what's going on with time.Sleep. I'll upload a CL.

Interesting. Thanks for investigating.

(Disabled in https://golang.org/cl/19171)

I can reproduce the issue in C with clock_gettime and nanosleep too, so (un?)fortunately it's not a Go runtime issue.

I used to have a fun bug label for tracking upstream OS problems but I think Russ deleted it. :)

I'm going to close this since I don't think there's really anything else to do on the Go side, and it doesn't make sense to track OpenBSD kernel work here. When/if OpenBSD fixes nanosleep() (which will be a non-trivial change), I think Go should Just Work.