time: Sleep significantly oversleeps on OpenBSD

[bradfitz]

This fails on OpenBSD 5.8 amd64 and 386 in the exact same way, while all other OS/arch are fine:

http://build.golang.org/log/f1fb777735c5d11326ef4473493b0b10ec376492

openbsd-amd64-gce58 at b3c05f08a97ac89064d3edbf4efb7bea671c2c18 building time at 3d9bcec796af48977d9ac9ca4a0445c8d09e5049

--- FAIL: TestLongRunningQPS (5.02s)
    rate_test.go:204: numOK = 251, want 601 (ideal 601.822131)
FAIL
FAIL    golang.org/x/time/rate  5.388s

Seems like maybe a legit OpenBSD [Go port?] issue.

/cc @mdempsky @4a6f656c

[bradfitz]

(Found while looking at subrepos for #11811)

[mdempsky]

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.

[bradfitz]

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

[mdempsky]

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

[mdempsky]

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.

[bradfitz]

Interesting. Thanks for investigating.

[bradfitz]

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

[mdempsky]

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

[bradfitz]

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

[mdempsky]

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.