Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

time: Sleep significantly oversleeps on OpenBSD #14183

Closed
bradfitz opened this issue Feb 1, 2016 · 10 comments

Comments

Projects
None yet
3 participants
@bradfitz
Copy link
Member

commented Feb 1, 2016

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 bradfitz added the OS-OpenBSD label Feb 1, 2016

@bradfitz bradfitz added this to the Unreleased milestone Feb 1, 2016

@bradfitz

This comment has been minimized.

Copy link
Member Author

commented Feb 1, 2016

(Found while looking at subrepos for #11811)

@mdempsky

This comment has been minimized.

Copy link
Member

commented Feb 1, 2016

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

This comment has been minimized.

Copy link
Member Author

commented Feb 1, 2016

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

This comment has been minimized.

Copy link
Member

commented Feb 1, 2016

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

@mdempsky mdempsky self-assigned this Feb 2, 2016

@mdempsky

This comment has been minimized.

Copy link
Member

commented Feb 2, 2016

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

This comment has been minimized.

Copy link
Member Author

commented Feb 2, 2016

Interesting. Thanks for investigating.

@mdempsky mdempsky changed the title x/time/rate: TestLongRunningQPS fails on OpenBSD amd64 and 386 time: Sleep significantly oversleeps on OpenBSD Feb 2, 2016

@bradfitz

This comment has been minimized.

Copy link
Member Author

commented Feb 2, 2016

@mdempsky

This comment has been minimized.

Copy link
Member

commented Feb 2, 2016

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

@bradfitz

This comment has been minimized.

Copy link
Member Author

commented Feb 2, 2016

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

@mdempsky

This comment has been minimized.

Copy link
Member

commented Feb 2, 2016

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.

@mdempsky mdempsky closed this Feb 2, 2016

@golang golang locked and limited conversation to collaborators Feb 3, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.