[issue44328] time.monotonic() should use a different clock source on Windows

Eryk Sun added the comment: >> Try changing EnterNonRecursiveMutex() to break out of the loop in >> this case > > This does work, but unfortunately a little too well - in a single > test I saw several instances where that approach returned > _earlier_ than the timeout. It's documented that

[issue44328] time.monotonic() should use a different clock source on Windows

Ryan Hileman added the comment: > It shouldn't behave drastically different just because the user closed the > laptop lid for an hour I talked to someone who's been helping with the Go time APIs and it seems like that holds pretty well for interactive timeouts, but makes no sense for

[issue44328] time.monotonic() should use a different clock source on Windows

Eryk Sun added the comment: > Seems like Windows 7 may need to be considered as well, as > per vstinner's bpo-32592 mention? Python 3.9 doesn't support Windows 7. Moreover, the interpreter DLL in 3.9 implicitly imports PathCchCanonicalizeEx, PathCchCombineEx, and PathCchSkipRoot, which

[issue44328] time.monotonic() should use a different clock source on Windows

Ryan Hileman added the comment: > The monotonic clock should thus be based on QueryUnbiasedInterruptTime My primary complaint here is that Windows is the only major platform with a low resolution monotonic clock. Using QueryUnbiasedInterruptTime() on older OS versions wouldn't entirely help

[issue44328] time.monotonic() should use a different clock source on Windows

Eryk Sun added the comment: On second thought, starting with Windows 8, WaitForSingleObject() and WaitForMultipleObjects() exclude time when the system is suspended. For consistency, an external deadline (e.g. for SIGINT support) should work the same way. The monotonic clock should thus be

[issue44328] time.monotonic() should use a different clock source on Windows

STINNER Victor added the comment: > To reduce the adverse effects of this frequency offset error, recent versions > of Windows, particularly Windows 8, use multiple hardware timers to detect > the frequency offset and compensate for it to the extent possible. This > calibration process is

[issue44328] time.monotonic() should use a different clock source on Windows

Ryan Hileman added the comment: I think a lot of that is based on very outdated information. It's worth reading this article: https://docs.microsoft.com/en-us/windows/win32/sysinfo/acquiring-high-resolution-time-stamps I will repeat Microsoft's current recommendation (from that article): >

[issue44328] time.monotonic() should use a different clock source on Windows

STINNER Victor added the comment: Changing is clock is a tricky. There are many things to consider: * Is it really monotonic in all cases? * Does it have a better resolution than the previous clock? * Corner cases: does it include time spent in time.sleep() and while the system is suspended?

[issue44328] time.monotonic() should use a different clock source on Windows

Change by Terry J. Reedy : -- nosy: +belopolsky, p-ganssle, vstinner versions: -Python 3.10, Python 3.8, Python 3.9 ___ Python tracker ___

[issue44328] time.monotonic() should use a different clock source on Windows

Ryan Hileman added the comment: Great information, thanks! > Windows 10 also provides QueryInterruptTimePrecise(), which is a hybrid > solution. It uses the performance counter to interpolate a timestamp between > interrupts. I'd prefer to use this for time.monotonic() instead of QPC, if >

[issue44328] time.monotonic() should use a different clock source on Windows

Eryk Sun added the comment: You resolved bpo-41299 using QueryPerformanceCounter(), so we're already a step toward making it the default monotonic clock. Personally, I've only relied on QPC for short intervals, but, as you've highlighted above, other language runtimes use it for their

[issue44328] time.monotonic() should use a different clock source on Windows

Ryan Hileman added the comment: I found these two references: - https://stackoverflow.com/questions/35601880/windows-timing-drift-of-performancecounter-c - https://bugs.python.org/issue10278#msg143209 Which suggest QueryPerformanceCounter() may be bad because it can drift. However, these