Ryan Hileman <lunixbo...@gmail.com> 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): > Windows has and will continue to invest in providing a reliable and efficient > performance counter. When you need time stamps with a resolution of 1 > microsecond or better and you don't need the time stamps to be synchronized > to an external time reference, choose QueryPerformanceCounter, > KeQueryPerformanceCounter, or KeQueryInterruptTimePrecise. When you need > UTC-synchronized time stamps with a resolution of 1 microsecond or better, > choose GetSystemTimePreciseAsFileTime or KeQuerySystemTimePrecise. (Based on that, it may also be worth replacing time.time()'s GetSystemTimeAsFileTime with GetSystemTimePreciseAsFileTime in CPython, as GetSystemTimePreciseAsFileTime is available in Windows 8 and newer) PEP 418: > It has a much higher resolution, but has lower long term precision than > GetTickCount() and timeGetTime() clocks. For example, it will drift compared > to the low precision clocks. Microsoft on drift (from the article above): > 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 performed when Windows is started. Modern Windows also automatically detects and works around stoppable TSC, as well as several other issues: > Some processors can vary the frequency of the TSC clock or stop the > advancement of the TSC register, which makes the TSC unsuitable for timing > purposes on these processors. These processors are said to have non-invariant > TSC registers. (Windows will automatically detect this, and select an > alternative time source for QPC). It seems like Microsoft considers QPC to be a significantly better time source now, than when PEP 418 was written. Another related conversation is whether Python can just expose all of the Windows clocks directly (through clock_gettime enums?), as that gives anyone who really wants full control over their timestamps a good escape hatch. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue44328> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
