TestSamplerConcurrent is flaky

[bufdev]

This happens sometimes:

$ make test
go test -race ./benchmarks/... ./buffer/... ./internal/... ./testutils/... ./zapcore/... .
ok  	go.uber.org/zap/benchmarks	1.150s [no tests to run]
ok  	go.uber.org/zap/buffer	1.100s
ok  	go.uber.org/zap/internal/bufferpool	1.123s
ok  	go.uber.org/zap/internal/exit	1.043s
ok  	go.uber.org/zap/internal/multierror	1.069s
ok  	go.uber.org/zap/internal/observer	1.160s
?   	go.uber.org/zap/testutils	[no test files]
--- FAIL: TestSamplerConcurrent (0.10s)
        Error Trace:    sampler_test.go:206
	Error:      	Max difference between 5000 and 4289 allowed is 500, but difference was 711
	Messages:   	Unexpected number of logs
FAIL
FAIL	go.uber.org/zap/zapcore	1.321s
ok  	go.uber.org/zap	1.724s
make: *** [test] Error 1
$ make test
go test -race ./benchmarks/... ./buffer/... ./internal/... ./testutils/... ./zapcore/... .
ok  	go.uber.org/zap/benchmarks	1.063s [no tests to run]
ok  	go.uber.org/zap/buffer	1.096s
ok  	go.uber.org/zap/internal/bufferpool	1.137s
ok  	go.uber.org/zap/internal/exit	1.069s
ok  	go.uber.org/zap/internal/multierror	1.094s
ok  	go.uber.org/zap/internal/observer	1.053s
?   	go.uber.org/zap/testutils	[no test files]
ok  	go.uber.org/zap/zapcore	2.256s
ok  	go.uber.org/zap	1.642s

[panlinux]

Hello,

I'm seeing this error in the Ubuntu and Debian autopkgtests, with varying values for how many logs were dropped. For example:

Max difference between 1250 and 595 allowed is 125, but difference was 655
Max difference between 1250 and 820 allowed is 125, but difference was 430
Max difference between 1250 and 922 allowed is 125, but difference was 328

Are these varying results related to machine performance?

This is with uber-zap 1.14.1 and golang-github-stretchr-testify-dev 1.4.0

The Ubuntu armhf failures can be seen here:
http://autopkgtest.ubuntu.com/packages/g/golang-go.uber-zap/groovy/armhf

Here is one in particular:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/armhf/g/golang-go.uber-zap/20200614_021731_d12b3@/log.gz

And here to the Debian failures in amd64:
https://ci.debian.net/packages/g/golang-go.uber-zap/testing/amd64/

[prashantv]

The test is sensitive to the resources available, unfortunately it relies on the real clock, and expects a certain amount of work to be done in that time.