In the Go runtime, on most platforms, we generally assume that thread-level sleeps (and other time-based things) try to wake up in an amount of time that's somewhere close to what we pass. The one exception here, across the runtime, is Windows. For Windows, we query interrupt time because it's more efficient, and work around sleeps that rounded to a clock with coarse granularity.

OpenBSD has a coarse-granularity clock for sleeps, but the runtime doesn't act like it. (Thanks @prattmic for digging up these links!) That results in situations like this one:

gc 22 @0.471s 78%: 19+20+0.018 ms clock, 76+0.14/0.22/0+0.072 ms cpu, 4->4->1 MB, 4 MB goal, 0 MB stacks, 0 MB globals, 4 P
gc 23 @0.511s 79%: 19+0.17+0.015 ms clock, 77+0.094/0.097/0.10+0.060 ms cpu, 4->4->1 MB, 4 MB goal, 0 MB stacks, 0 MB globals, 4 P
gc 24 @0.531s 79%: 19+0.20+0.017 ms clock, 76+0.11/0.092/0.12+0.068 ms cpu, 4->4->1 MB, 4 MB goal, 0 MB stacks, 0 MB globals, 4 P
gc 25 @0.551s 80%: 19+0.23+0.016 ms clock, 76+0.086/0.079/0.10+0.064 ms cpu, 4->4->1 MB, 4 MB goal, 0 MB stacks, 0 MB globals, 4 P
gc 26 @0.571s 80%: 19+0.17+0.014 ms clock, 76+0.095/0.084/0.10+0.057 ms cpu, 4->4->1 MB, 4 MB goal, 0 MB stacks, 0 MB globals, 4 P
gc 27 @0.591s 81%: 19+0.17+0.004 ms clock, 77+0.084/0.091/0.10+0.016 ms cpu, 4->4->1 MB, 4 MB goal, 0 MB stacks, 0 MB globals, 4 P
gc 28 @0.611s 81%: 19+0.16+0.016 ms clock, 77+0.089/0.083/0.10+0.066 ms cpu, 4->4->1 MB, 4 MB goal, 0 MB stacks, 0 MB globals, 4 P
gc 29 @0.631s 79%: 19+20+0.003 ms clock, 77+0/0.16/2.1+0.014 ms cpu, 5->6->3 MB, 6 MB goal, 0 MB stacks, 0 MB globals, 4 P
gc 30 @0.671s 80%: 19+0.13+0.013 ms clock, 77+0.096/0.084/0.10+0.055 ms cpu, 5->5->2 MB, 6 MB goal, 0 MB stacks, 0 MB globals, 4 P
gc 31 @0.691s 78%: 19+19+0.015 ms clock, 77+0.060/0.30/0.17+0.060 ms cpu, 4->10->8 MB, 4 MB goal, 0 MB stacks, 0 MB globals, 4 P

The above text is a GC trace for TestDecodeMemoryConsumption in the image/gif package. Note the very high GC stop-the-world times for the transition to the mark phase. This is time not spent in the pause, but actually trying to stop the world:

Typically the runtime is waiting on one P, and it goes to sleep on a note for 100µs. If undisturbed, it takes between 10 and 20 ms to actually wake up. But that should be OK, because it's woken up early if the last P to stop actually stops. Except that we have thread-level sleeps in other parts of the runtime that have the same latency! For example, runqgrab might call usleep(3), but that too takes 10-20ms to return. This was a common one I discovered (and confirmed as a source of latency) and there are sure to be more.

The runtime needs to be overhauled for the OpenBSD port to treat sleeps as we would on Windows.

This is closely related to #14183.