Each failure is only for some or all of the tests that use closedPortDelay. That is measured before running the tests by actually calling Dial to connect to a closed port. The test gives an error if the test produces a result that is more than 95 milliseconds faster than the measured delay. Case 7 above adds an additional 200 millisecond delay which I believe is meant to correspond to the 300 milliseconds used in (*Dialer).fallbackDelay.

In the case above the measured closedPortDelay was evidently about 1.1 seconds. The results of the test were then about 1 second, and the test failed because the difference was more than 95 milliseconds.

Looks like the use 95 milliseconds was added in patchset 8 of https://golang.org/cl/8768, along with the comment

The issue on Windows is that connecting to a closed port always takes 1 second to fail, instead of being instantaneous like Linux. This is not specific to Go, and there's no obvious way around it.

So I've updated TestDialParallel to measure the delay, and expect Windows to have different timing behavior.

For the four failures listed above, the largest closedPortDelay is 1.1125066s. The shortest time for a failed connection during the actual test is 1.0000027s. The difference between those is 112.5ms, which is more than the expected maximum difference of 95ms.

I can't see any special meaning to 95ms, so I'll send a CL to push up the value on Windows.

Change https://golang.org/cl/207466 mentions this issue: net: add more timing slop for TestDialParallel on Windows

@gopherbot Please consider for backport to 1.13. This is merely a test fix for a flaky test. It's needed to help #29252.

Backport issue(s) opened: #39538 (for 1.13).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases.

Change https://golang.org/cl/237602 mentions this issue: [release-branch.go1.13] net: add more timing slop for TestDialParallel on Windows