在 CL 366176 (对于 #36108 )中，我将 net.TestWriteTimeoutFluctuation 和 net.TestReadTimeoutFluctuation 中的超时间隙提高了33%,即使对于具有非常慷慨(多秒)超时的测试也是如此。在这个规模上，这个间隙应该对即使是负载很重的构建器来说也很容易达到。
不幸的是，NetBSD 和 OpenBSD 的构建器仍然无法可靠地达到它，即使在一个似乎不受 #49209 影响的 n1 示例上也是如此。
考虑到我们在 NetBSD 和 OpenBSD 上遇到的其他问题，我怀疑这是一个内核错误。我计划进一步增加这两个平台的间隙，在其他地方缩小它，并在没有进一步调查的情况下调用它。然而，我建议那些关心这些内核的人(@bsiegert,@coypoop,@4a6f656c?)可能想看看底层的系统调用是否在超时处理中添加了不必要的间隙。greplogs --dashboard -md -l -e 'FAIL: TestWriteTimeoutFluctuation' --since=2021-11-23
2021-12-13T16:09:22-d198a36/openbsd-amd64-70-n2d
2021-11-29T19:45:58-f598e29/netbsd-amd64-9_0-n1
2021-11-29T16:08:23-a59ab29/openbsd-amd64-68
2021-11-25T00:07:28-f7e34e7/openbsd-amd64-70-n1
2021-11-25T00:07:11-c58243a/openbsd-amd64-70-n1
6条答案
按热度按时间csbfibhn1#
https://golang.org/cl/372215提到了这个问题：
net: increase timing slop in TimeoutFluctuation tests on NetBSD and OpenBSD6za6bjd02#
Expanding the regexp a bit to catch related tests:
greplogs --dashboard -md -l -e 'FAIL: Test(?:Read|ReadFrom|Write)TimeoutFluctuation' --since=2021-11-192021-12-13T16:09:22-d198a36/openbsd-amd64-70-n2d
2021-12-03T14:28:11-a174638/netbsd-386-9_0-n2d
2021-12-02T05:25:23-00dbcb3/netbsd-386-9_0
2021-12-01T22:20:39-c3a7fb2/openbsd-amd64-70
2021-11-30T20:04:58-7ccbcc9/openbsd-amd64-70-n1
2021-11-29T22:02:51-ebd0b77/openbsd-amd64-70
2021-11-29T22:02:45-1970e3e/openbsd-amd64-70
2021-11-29T19:45:58-f598e29/netbsd-amd64-9_0-n1
2021-11-29T16:08:23-a59ab29/openbsd-amd64-68
2021-11-27T23:27:52-9f2a075/openbsd-amd64-70-n1
2021-11-27T19:49:32-a142d65/openbsd-amd64-70-n1
2021-11-25T00:07:28-f7e34e7/openbsd-amd64-70-n1
2021-11-25T00:07:11-c58243a/openbsd-amd64-70-n1
2021-11-24T21:09:36-7e5331a/openbsd-amd64-70-n1
2021-11-24T20:53:54-a3b8f62/openbsd-amd64-70-n1
2021-11-22T18:55:55-2d7ae3f/openbsd-amd64-70
2021-11-22T18:50:19-9e94cc3/netbsd-amd64-9_0-n1
2021-11-22T18:50:19-9e94cc3/openbsd-amd64-70
2021-11-22T16:53:57-cd0bf38/netbsd-386-9_0-n1
2021-11-22T16:53:57-cd0bf38/netbsd-amd64-9_0
2021-11-22T16:15:36-6275b54/netbsd-386-9_0
2021-11-22T16:15:36-6275b54/netbsd-amd64-9_0-n1
2021-11-22T15:54:11-e73c6c8/netbsd-amd64-9_0
2021-11-22T12:30:26-b2aa138/netbsd-amd64-9_0-n1
2021-11-22T12:30:26-b2aa138/openbsd-amd64-70
2021-11-22T12:29:44-ffb6c79/netbsd-386-9_0
2021-11-22T12:29:44-ffb6c79/netbsd-amd64-9_0-n1
2021-11-22T12:29:44-ffb6c79/openbsd-amd64-70
2021-11-22T04:27:29-e30ebaa/netbsd-amd64-9_0
2021-11-22T03:24:07-a287c4a/openbsd-amd64-68
2021-11-22T03:24:01-0c3b4a3/netbsd-amd64-9_0
2021-11-22T03:24:01-0c3b4a3/openbsd-amd64-68
2021-11-22T03:24:01-0c3b4a3/openbsd-amd64-70
2021-11-20T08:47:36-91abe4b/netbsd-386-9_0-n1
2021-11-20T08:47:36-91abe4b/netbsd-amd64-9_0
2021-11-20T08:47:36-91abe4b/openbsd-amd64-70
2021-11-20T00:37:28-d2f4c93/netbsd-386-9_0
2021-11-20T00:32:49-57aba32/netbsd-amd64-9_0
2021-11-19T21:59:14-5e774b0/netbsd-386-9_0-n1
2021-11-19T21:59:14-5e774b0/openbsd-amd64-70
jgovgodb3#
https://golang.org/cl/383175提到了这个问题：
rate: allow for more timing slop in TestWaitSimplewz8daaqr4#
关于可能导致额外"误差"的理论：
在NetBSD(不确定OpenBSD)上，睡眠和类似的粒度是以一个名为HZ的内核常量为单位的，其默认值为100。因此，不幸的是，对下一个10毫秒边界的抖动是预期的。
3duebb1j5#
@bsiegert,经验上来说，误差量并不是一个常数——或者说，如果它是一个常数，那么这个常数也大于一秒。许多测试失败都以尝试睡眠3-5秒的次数结束，并且错过了目标超过一秒。
(我同意将误差量四舍五入到一个与系统相关的亚秒级精度是合理的和预期的，但这似乎不是这里的情况。)
mkh04yzy6#
https://go.dev/cl/415234提到了这个问题：
os: simplify deadline fluctuation tests