On the same Windows 7 virtual machine, but with HPET disabled, the test pass.

[1/1] test_asyncio
test_timeout_rounding (test.test_asyncio.test_events.ProactorEventLoopTests) ...
 GetQueuedCompletionStatus(2 ms)->None took 4.350 ms (monotonic: 16.000 ms)
GetQueuedCompletionStatus(10 ms)->None took 14.737 ms (monotonic: 16.000 ms)
GetQueuedCompletionStatus(2 ms)->None took 14.700 ms (monotonic: 15.000 ms)
GetQueuedCompletionStatus(2 ms)->None took 12.553 ms (monotonic: 16.000 ms)
GetQueuedCompletionStatus(2 ms)->None took 15.076 ms (monotonic: 15.000 ms)
GetQueuedCompletionStatus(2 ms)->None took 14.524 ms (monotonic: 16.000 ms)
GetQueuedCompletionStatus(2 ms)->None took 14.861 ms (monotonic: 16.000 ms)
GetQueuedCompletionStatus(2 ms)->None took 14.617 ms (monotonic: 15.000 ms)
GetQueuedCompletionStatus(0 ms)->None took 0.012 ms (monotonic: 0.000 ms)
ok

As you can see, the elapsed monotonic time if only zero when the timeout was zero, otherwise it is at least 15 ms.

So to fix the performance issue on Windows with HPET enabled, I see 3 options:

- round the timeout of GetQueuedCompletionStatus() (asyncio module) and select.select() (select module) using the resolution of the clock
- use a more precise clock: time.perf_counter(). I don't like this clock because it is not reliable, especially on duration longer than 2 minutes
- reintroduce the granularity in asyncio (and maybe resolution in selectors): for this specific issue (Windows with HPET enabled), only the resolution of the clock matters in fact

IMO the granularity is the best option because it only modify asyncio and is simple. We can try to leave selectors unchanged.

Note: only poll and epoll selectors round away from zero. select and kqueue round towards zero. But it's not important IMO.