This seems to be a regression with Go 1.16 time.Sleep.
What version of Go are you using (go version)?
$ go version
go version go1.16 windows/amd64
Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=Z:\gocache
set GOENV=C:\Users\egone\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=F:\Go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=F:\Go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=c:\go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=c:\go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.16
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=f:\temp\sleep\go.mod
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=Z:\Temp\go-build3014714148=/tmp/go-build -gno-record-gcc-switches
What did you do?
package main
import (
"fmt"
"time"
"github.com/loov/hrtime"
)
func main() {
b := hrtime.NewBenchmark(100)
for b.Next() {
time.Sleep(50 * time.Microsecond)
}
fmt.Println(b.Histogram(10))
}
hrtime is a package that uses RDTSC for time measurements.
Output on Windows 10:
> go1.16 run .
avg 15.2ms; min 55.3µs; p50 15.5ms; max 16.3ms;
p90 16.1ms; p99 16.3ms; p999 16.3ms; p9999 16.3ms;
55.3µs [ 2] █
2ms [ 0]
4ms [ 0]
6ms [ 0]
8ms [ 0]
10ms [ 1] ▌
12ms [ 0]
14ms [ 75] ████████████████████████████████████████
16ms [ 22] ███████████▌
18ms [ 0]
> go1.15.8 run .
avg 1.03ms; min 63.9µs; p50 1ms; max 2.3ms;
p90 1.29ms; p99 2.3ms; p999 2.3ms; p9999 2.3ms;
63.9µs [ 1] ▌
500µs [ 47] ███████████████████████████████████████
1ms [ 48] ████████████████████████████████████████
1.5ms [ 1] ▌
2ms [ 3] ██
2.5ms [ 0]
3ms [ 0]
3.5ms [ 0]
4ms [ 0]
4.5ms [ 0]
Output on Linux (Debian 10):
$ go1.16 run test.go
avg 1.06ms; min 1.06ms; p50 1.06ms; max 1.08ms;
p90 1.07ms; p99 1.08ms; p999 1.08ms; p9999 1.08ms;
1.06ms [ 4] █▌
1.07ms [ 84] ████████████████████████████████████████
1.07ms [ 7] ███
1.08ms [ 3] █
1.08ms [ 1]
1.09ms [ 1]
1.09ms [ 0]
1.1ms [ 0]
1.1ms [ 0]
1.11ms [ 0]
$ go1.15.8 run test.go
avg 86.7µs; min 57.3µs; p50 83.6µs; max 132µs;
p90 98.3µs; p99 132µs; p999 132µs; p9999 132µs;
57.3µs [ 2] █
60µs [ 1] ▌
70µs [ 13] ████████
80µs [ 64] ████████████████████████████████████████
90µs [ 11] ██████▌
100µs [ 2] █
110µs [ 1] ▌
120µs [ 3] █▌
130µs [ 3] █▌
140µs [ 0]
The time granularity shouldn't be that bad even for Windows. So, there might be something going wrong somewhere.
This seems to be a regression with Go 1.16
time.Sleep.What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
hrtimeis a package that usesRDTSCfor time measurements.Output on Windows 10:
Output on Linux (Debian 10):
The time granularity shouldn't be that bad even for Windows. So, there might be something going wrong somewhere.