Occasional failure in installed 3.13.0 test_int

[terryjreedy]

On Windows, on tests of 1 and about 14 of 16, so maybe 1 in 10: same failure.

0:00:10 load avg: 11.46 [223/478/1] test_int failed (1 failure)
test test_int failed -- Traceback (most recent call last):
  File "C:\Programs\Python313\Lib\test\test_int.py", line 738, in test_denial_of_service_prevented_str_to_int
    self.assertLessEqual(sw_fail_extra_huge.seconds, sw_convert.seconds/2)
    ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: 0.015625 not less than or equal to 0.0078125

I expect not Windows specific

[zware]

I've seen this now and then on buildbots. I believe it is Windows-specific and due to clock resolution.

[terryjreedy]

If so, then the assertion value should be doubled on Windows.

[terryjreedy]

@encukou The failing line 738 is one you merged.

[gpshead]

if it is only being flaky on a specific platform feel free to add a platform specific skip. we only need this to run in CI on at least one tier1 platform. 0.015625 not less than or equal to 0.0078125 suggests the timer resolution is 0.0078125 and thus it's easy to be skewed by interruptions or aliasing around timer tick boundaries. potentially more common on faster machines.

[gpshead]

(this skip is worth backporting to all branches that contain this test)

[skirpichev]

(All supported branches have this test.)

[encukou]

For background: since this test was added, converting to str was optimized so much that it takes less than a Windows clock tick. But, I haven't been able to reproduce this reliably outside buildbots.

@terryjreedy, do you see this on a machine where you could test a fix?

The failing line 738 is one you merged.

Yes, for #114911, I factored out similar logic from a couple of places in the tests. I didn't make the timeouts smaller. (Didn't mean to, anyway.)
That issue is still open. I'll close this as duplicate.