timer: TestTicker fail

[toralf]

I do maintain and run a build bot for Gentoo packages. Inside one of the running images (bubblewrap'ed images) the mentioned test case fails. The approproiate Gentoo dev [2] is arguing that the environment of the tinderbox harms the test case scenario.
The build bot is a recent zen3 with enough RAM. For a good overall throuput however I do chain each image via cgroups to 2 CPUs. Furthermore I do set [3]

EGO_BUILD_FLAGS="-p ${jobs}"
GO19CONCURRENTCOMPILATION=0

with jobs=2 or jobs=3 usually.
Does this by any chance harms the test case ?

[1] https://github.com/toralf/tinderbox
[2] https://bugs.gentoo.org/792963#c7
[3] https://github.com/toralf/tinderbox/blob/master/bin/setup_img.sh#L393

[seankhliao]

Is this a reproducible failure or a one off? how are you limiting CPU resources? and how loaded is the system (hardware) overall?

[ianlancetaylor]

From https://bugs.gentoo.org/792963 the beginning of the failure report is

--- FAIL: TestTicker (2.80s)
    tick_test.go:79: saw 5 errors
    tick_test.go:37: 10 20ms ticks took 599.673629ms, expected [240ms,360ms]
    tick_test.go:37: 10 20ms ticks took 500.305963ms, expected [240ms,360ms]
    tick_test.go:37: 10 20ms ticks took 586.319661ms, expected [240ms,360ms]

This certainly suggests that there is something wrong but it's hard to know what. I don't know what tinderbox does. The environment variables you mention should not make any difference to this test.

This test can fail in this way if the machine is very busy, or if it is run in an environment in which the epoll system call does not honor its timeout with a reasonable granularity. Because the test is affected by system busyness, the test is run five times with a delay in between, and only if all five cases fail is a failure reported.

[toralf]

Each image is given a cgroup v1 quota of usually 2.1 cpu if run with "make -j2" (https://github.com/toralf/tinderbox/blob/master/bin/bwrap.sh#L30) I can see that go spawns always much more threads as if could be used all 32 CPUs. The system is under load, yes - it is a build bot.

I will repeat the tests.

[ianlancetaylor]

Is there some way that the Go runtime could know that it only has a limited number of CPUs available? Currently on Linux systems the Go runtime determines the number of CPUs available by using the sched_getaffinity system call.

[bcmills]

This looks like the same failure mode as #35692 and #37332.

On CL 313849, I suggested that this measurement would be better suited to a benchmark rather than a test.

[gopherbot]

Change https://golang.org/cl/339892 mentions this issue: time: fallback to slower TestTicker test after one failure

[joedian]

Fixed.