classification
Title: Use GetTickCount/GetTickCount64 instead of QueryPerformanceCounter for monotonic clock
Type: Stage:
Components: Library (Lib), Windows Versions: Python 3.3
process
Status: closed Resolution: duplicate
Dependencies: Superseder:
Assigned To: Nosy List: Yury.Selivanov, brian.curtin, haypo, lemburg, loewis, python-dev, tim.golden
Priority: normal Keywords:

Created on 2012-03-24 10:44 by haypo, last changed 2012-04-29 00:44 by python-dev. This issue is now closed.

Messages (7)
msg156690 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2012-03-24 10:44
QueryPerformanceCounter() is not monotonic on a multiprocessor computer on Windows XP. Extract of its documentation:

"Remarks

On a multiprocessor computer, it should not matter which processor is called. However, you can get different results on different processors due to bugs in the basic input/output system (BIOS) or the hardware abstraction layer (HAL). To specify processor affinity for a thread, use the SetThreadAffinityMask function." 

See also:
http://bytes.com/topic/python/answers/527849-time-clock-going-backwards

time.steady(strict-True) (or "time.monotonic()"? the function name is not decided yet :§)) should use GetTickCounter64(), or GetTickCounter().

GetTickCount64() was added to Windows Seven / Server 2008. GetTickCount() overflows after 49 days.

QueryPerformanceCounter() has a better resolution than
GetTickCount[64]() and so it's maybe better to keep it for time.steady(strict-False)?
msg156694 - (view) Author: Yury Selivanov (Yury.Selivanov) * Date: 2012-03-24 13:56
I vote for adding just one function to the 'time' module: monotonic(),
which should exist only if the host OS support it.  

And I don't see the point of having 'steady()' at all.
msg156695 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2012-03-24 14:20
A monotonic clock is not suitable for measuring durations, as it may still jump forward. A steady clock will not.
msg156718 - (view) Author: Yury Selivanov (Yury.Selivanov) * Date: 2012-03-24 20:14
> A monotonic clock is not suitable for measuring durations, as it may still jump forward. A steady clock will not.

Well, Victor's implementation of 'steady()' is just a tiny wrapper, which uses 'monotonic()' or 'time()' if the former is not available.  Hence 'steady()' is a misleading name.
msg156748 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2012-03-25 10:24
Yury Selivanov wrote:
> 
> Yury Selivanov <yselivanov@gmail.com> added the comment:
> 
>> A monotonic clock is not suitable for measuring durations, as it may still jump forward. A steady clock will not.
> 
> Well, Victor's implementation of 'steady()' is just a tiny wrapper, which uses 'monotonic()' or 'time()' if the former is not available.  Hence 'steady()' is a misleading name.

Agreed.

I think time.monotonic() is a better name.
msg157450 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2012-04-04 00:18
I'm closing this issue as a duplicate... of the PEP 418. See the python-dev mailing list for discussions on this PEP.
msg159553 - (view) Author: Roundup Robot (python-dev) Date: 2012-04-29 00:44
New changeset 76d2e0761d18 by Victor Stinner in branch 'default':
Issue #14428, #14397: Implement the PEP 418
http://hg.python.org/cpython/rev/76d2e0761d18
History
Date User Action Args
2012-04-29 00:44:14python-devsetnosy: + python-dev
messages: + msg159553
2012-04-04 00:18:28hayposetstatus: open -> closed
resolution: duplicate
messages: + msg157450
2012-03-25 10:24:27lemburgsetnosy: + lemburg
messages: + msg156748
2012-03-24 20:14:29Yury.Selivanovsetmessages: + msg156718
2012-03-24 14:20:17loewissetmessages: + msg156695
2012-03-24 13:56:08Yury.Selivanovsetmessages: + msg156694
2012-03-24 13:53:14Yury.Selivanovsetnosy: + Yury.Selivanov
2012-03-24 10:45:44hayposetnosy: + loewis, tim.golden, brian.curtin
2012-03-24 10:44:41haypocreate