Use GetTickCount/GetTickCount64 instead of QueryPerformanceCounter for monotonic clock

[vstinner]

BPO	14397
Nosy	@malemburg, @loewis, @vstinner, @tjguk, @briancurtin

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2012-04-04.00:18:28.681>
created_at = <Date 2012-03-24.10:44:41.119>
labels = ['library', 'OS-windows']
title = 'Use GetTickCount/GetTickCount64 instead of QueryPerformanceCounter for monotonic clock'
updated_at = <Date 2012-04-29.00:44:14.015>
user = 'https://github.com/vstinner'

bugs.python.org fields:

activity = <Date 2012-04-29.00:44:14.015>
actor = 'python-dev'
assignee = 'none'
closed = True
closed_date = <Date 2012-04-04.00:18:28.681>
closer = 'vstinner'
components = ['Library (Lib)', 'Windows']
creation = <Date 2012-03-24.10:44:41.119>
creator = 'vstinner'
dependencies = []
files = []
hgrepos = []
issue_num = 14397
keywords = []
message_count = 7.0
messages = ['156690', '156694', '156695', '156718', '156748', '157450', '159553']
nosy_count = 7.0
nosy_names = ['lemburg', 'loewis', 'vstinner', 'tim.golden', 'brian.curtin', 'Yury.Selivanov', 'python-dev']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue14397'
versions = ['Python 3.3']

[vstinner]

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
GetTickCount64 and so it's maybe better to keep it for time.steady(strict-False)?

[YurySelivanov]

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.

[loewis]

A monotonic clock is not suitable for measuring durations, as it may still jump forward. A steady clock will not.

[YurySelivanov]

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.

[malemburg]

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.

[vstinner]

I'm closing this issue as a duplicate... of the PEP-418. See the python-dev mailing list for discussions on this PEP.

[python-dev]

New changeset 76d2e0761d18 by Victor Stinner in branch 'default':
Issue bpo-14428, bpo-14397: Implement the PEP-418
http://hg.python.org/cpython/rev/76d2e0761d18