[Python-Dev] PEP 418: Add monotonic clock (original) (raw)

Victor Stinner victor.stinner at gmail.com
Wed Mar 28 02:36:18 CEST 2012

Scott wrote:

<< The Boost implementation can be summarized as:

system_clock:

mac = gettimeofday posix = clock_gettime(CLOCK_REALTIME) win = GetSystemTimeAsFileTime

steady_clock:

mac = mach_absolute_time posix = clock_gettime(CLOCK_MONOTONIC) win = QueryPerformanceCounter

high_resolution_clock:

I read again the doc of the QElapsedTimer class of the Qt library. So Qt and Boost agree to say that QueryPerformanceCounter() is monotonic.

I was confused because of a bug found in 2006 in Windows XP on multicore processors. QueryPerformanceCounter() gave a different value on each core. The bug was fixed in Windows and is known as KB896256 (I already added a link to the bug in the PEP).

I added a time.hires() clock to the PEP for the benchmarking/profiling use case (...) It is this always-having-to-manually-fallback-depending-on-os that I was hoping your new functionality would avoid. Is time.trymonotonic() suitable for this usecase?

If QueryPerformanceCounter() is monotonic, the API can be simplified to:

time.hires() definition is exactly what I was trying to implement with "time.steady(strict=True)" / "time.try_monotonic()".

--

Scott> monotonic_clock = always goes forward but can be adjusted Scott> steady_clock = always goes forward and cannot be adjusted

I don't know if the monotonic clock should be called time.monotonic() or time.steady(). The clock speed can be adjusted by NTP, at least on Linux < 2.6.28.

I don't know if other clocks used by my time.monotonic() proposition can be adjusted or not.

If I understand correctly, time.steady() cannot be implemented using CLOCK_MONOTONIC on Linux because CLOCK_MONOTONIC can be adjusted?

Does it really matter if a monotonic speed is adjusted?

Victor

More information about the Python-Dev mailing list