It seems that the relaxed timings in some tests are still not
sufficient:

http://buildbot.python.org/all/builders/AMD64%20OpenIndiana%203.x/builds/7417/steps/test/logs/stdio

======================================================================
FAIL: test_time_and_call_at (test.test_asyncio.test_base_events.BaseEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_asyncio/test_base_events.py", line 127, in test_time_and_call_at
    self.assertTrue(0.09 <= t1-t0 <= 0.9, t1-t0)
AssertionError: False is not true : 2.06036564335227

I won't have time to fix this (and bardly to even review a fix) but this seems a straightforward fix and you can go ahead without me -- maybe you can get someone else with some asyncio experience to review your patch (e.g. Antoine or Victor).

I'm seeing other unrelated timeouts on the OpenIndiana machines.
Jesús, are the machines perhaps operating under an unusually high load?

> I'm seeing other unrelated timeouts on the OpenIndiana machines.

I read somewhere that the host of these virtual machines is *highly* loaded (load > 6). It's more a buildbot configuration issue than a test_asyncio issue.

I see. That's astonishing, because usually the builds are ultra-fast
on those machines.

Tests failing because of timings is really annoying. It would be nice to add something in test.support to configure timings. A function can maybe wait until the system load is lower than a threshold, or we should add a parameter to configure a tolerance between the perfect timing and the expected timing.

The tolerance can be a simple factor, a floating point number >= 1.0.

For example, replace:
    0.09 <= t1-t0 <= 0.9, t1-t0
with
    0.1 - 0.01 * factor <= t1-t0 <= 0.1 + 0.8 * factor
or a new test function:
    check_timing(t1-t0, 0.1, 0.01, 0.8)

+1 for doing something about timing failures. Perhaps also a
decorator @skip_if_load_higher_than(x).


[Nick, I'm adding you because our current test suite could lead
to "commit impossible" situations with Zuul.]

I have a draft PEP for the Zuul idea, and yes, it notes the increased consequences of declaring a buildbot stable when it sometimes isn't. There's a reason OpenStack treats third party test results as advisory only rather than as gating criteria :P

Let's open a new issue for system load detection. This one is not asyncio specific.

> Let's open a new issue for system load detection. This one is not asyncio specific.

I opened issues #20910 and #20964 for example.