PEP 418: Add monotonic clock

classic Classic list List threaded Threaded
155 messages Options
1234 ... 8
Reply | Threaded
Open this post in threaded view
|

PEP 418: Add monotonic clock

Victor Stinner-3
Hi,

I started to write the PEP 418 to clarify the notions of monotonic and
steady clocks.

The PEP is a draft and everyone is invited to contribute!

http://www.python.org/dev/peps/pep-0418/
http://hg.python.org/peps/file/tip/pep-0418.txt

Victor
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 418: Add monotonic clock

Victor Stinner-3
> I started to write the PEP 418 to clarify the notions of monotonic and
> steady clocks.
>
> The PEP is a draft and everyone is invited to contribute!

time.steady() doesn't fit the benchmarking use case: it looks like we
have to decide between stability and clock resolution.

QueryPerformanceCounter() has a good resolution for benchmarking, but
it is not monotonic and so GetTickCount64() would be used for
time.steady(). GetTickCount64() is monotonic but has only a resolution
of 1 millisecond.

We might add a third new function which provides the most accurate
clock with or without a known starting point. We cannot use
QueryPerformanceCounter() to enhance time.time() resolution because it
has an unknown starting point.

Victor
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 418: Add monotonic clock

Scott Dial
In reply to this post by Victor Stinner-3
On 3/26/2012 7:32 PM, Victor Stinner wrote:
> I started to write the PEP 418 to clarify the notions of monotonic and
> steady clocks.

"""
time.steady
This clock advances at a steady rate relative to real time. It may be
adjusted.
"""

Please do not call this "steady". If the clock can be adjusted, then it
is not "steady" by any acceptable definition. I cannot fathom the
utility of this function other than as a function that provides an
automatic fallback from "time.monotonic()". More importantly: this
definition of "steady" is in conflict with the C++0x definition of
"steady" that is where you sourced this named from![1]

"""
time.steady(strict=False) falls back to another clock if no monotonic
clock is not available or does not work, but it does never fail.
"""

As I say above, that is so far away from what "steady" implies that this
is a misnomer. What you are describing is a best-effort clock, which
sounds a lot more like the C++0x "high resolution" clock.

"""
time.steady(strict=True) raises OSError if monotonic clock fails or
NotImplementedError if the system does not provide a monotonic clock
"""

What is the utility of "strict=True"? If I wanted that mode of
operation, then why would I not just try to use "time.monotonic()"
directly? At worst, it generates an "AttributeError" (although that is
not clear from your PEP). What is the use case for "strict=True" that is
not covered by your "time.monotonic()"?

If you want to define new clocks, then I wish you would use the same
definitions that C++0x is using. That is:

  system_clock = wall clock time
  monotonic_clock = always goes forward but can be adjusted
  steady_clock = always goes forward and cannot be adjusted
  high_resolution_clock = steady_clock || system_clock

Straying from that is only going to create confusion. Besides that, the
one use case for "time.steady()" that you give (benchmarking) is better
served by a clock that follows the C++0x definition. As well, certain
kinds of scheduling/timeouts would be better implemented with the C++0x
definition for "steady" rather than the "monotonic" one and vice-versa.

Rather, it seems you have a particular use-case in mind and have settled
on calling that a "steady" clock despite how it belies its name.

[1]
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3128.html#time.clock.steady

"""
Objects of class steady_clock represent clocks for which values of
time_point advance at a steady rate relative to real time. That is, the
clock may not be adjusted.
"""

--
Scott Dial
[hidden email]
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 418: Add monotonic clock

zooko
>  system_clock = wall clock time
>  monotonic_clock = always goes forward but can be adjusted
>  steady_clock = always goes forward and cannot be adjusted
>  high_resolution_clock = steady_clock || system_clock

Note that the C++ standard deprecated monotonic_clock once they
realized that there is absolutely no point in having a clock that
jumps forward but not back, and that none of the operating systems
implement such a thing -- instead they all implement a clock which
doesn't jump in either direction.

http://stackoverflow.com/questions/6777278/what-is-the-rationale-for-renaming-monotonic-clock-to-steady-clock-in-chrono

In other words, yes! +1! The C++ standards folks just went through the
process that we're now going through, and if we do it right we'll end
up at the same place they are:

http://en.cppreference.com/w/cpp/chrono/system_clock

"""
system_clock represents the system-wide real time wall clock. It may
not be monotonic: on most systems, the system time can be adjusted at
any moment. It is the only clock that has the ability to map its time
points to C time, and, therefore, to be displayed.

steady_clock: monotonic clock that will never be adjusted

high_resolution_clock: the clock with the shortest tick period available
"""

Note that we don't really have the option of providing a clock which
is "monotonic but not steady" in the sense of "can jump forward but
not back". It is a misunderstanding (doubtless due to the confusing
name "monotonic") to think that such a thing is offered by the
underlying platforms. We can choose to *call* it "monotonic",
following POSIX instead of calling it "steady", following C++.

Regards,

Zooko
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 418: Add monotonic clock

Matt Joiner

So does anyone care to dig into the libstd++/boost/windoze implementation to see how they each did steady_clock?


_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 418: Add monotonic clock

Scott Dial
On 3/26/2012 10:59 PM, Matt Joiner wrote:
> So does anyone care to dig into the libstd++/boost/windoze
> implementation to see how they each did steady_clock?

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:

  * = { steady_clock, if available
        system_clock, otherwise }

Whether or not these implementations meet the specification is an
exercise left to the reader..

--
Scott Dial
[hidden email]
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 418: Add monotonic clock

Matt Joiner

Cheers, that clears things up.


_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 418: Add monotonic clock

Jeffrey Yasskin-2
In reply to this post by Victor Stinner-3
FWIW, I'm not sure you're the right person to drive time PEPs. You
don't seem to have come into it with much knowledge of time, and it's
taken several repetitions for you to take corrections into account in
both this discussion and the Decimal/datetime representation PEP.

On Mon, Mar 26, 2012 at 4:32 PM, Victor Stinner
<[hidden email]> wrote:

> Hi,
>
> I started to write the PEP 418 to clarify the notions of monotonic and
> steady clocks.
>
> The PEP is a draft and everyone is invited to contribute!
>
> http://www.python.org/dev/peps/pep-0418/
> http://hg.python.org/peps/file/tip/pep-0418.txt
>
> Victor
> _______________________________________________
> Python-Dev mailing list
> [hidden email]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/jyasskin%40gmail.com
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 418: Add monotonic clock

Nick Coghlan
On Tue, Mar 27, 2012 at 3:51 PM, Jeffrey Yasskin <[hidden email]> wrote:
> FWIW, I'm not sure you're the right person to drive time PEPs. You
> don't seem to have come into it with much knowledge of time, and it's
> taken several repetitions for you to take corrections into account in
> both this discussion and the Decimal/datetime representation PEP.

The main things required to be a PEP champion are passion and a
willingness to listen to expert feedback and change course in
response. If someone lacks the former, they will lose steam and their
PEP will eventually be abandoned. If they don't listen to expert
feedback, then their PEP will ultimately be rejected (sometimes a PEP
will be rejected anyway as a poor fit for the language *despite* being
responsive to feedback, but that's no slight to the PEP author).

Victor has shown himself to be quite capable of handling those aspects
of the PEP process, and the topics he has recently applied himself to
are ones where it is worthwhile having a good answer in the standard
library for Python 3.3.

Cheers,
Nick.

--
Nick Coghlan   |   [hidden email]   |   Brisbane, Australia
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 418: Add monotonic clock

Paul Moore
In reply to this post by Scott Dial
On 27 March 2012 01:23, Scott Dial <[hidden email]> wrote:
> If you want to define new clocks, then I wish you would use the same
> definitions that C++0x is using. That is:
>
>  system_clock = wall clock time
>  monotonic_clock = always goes forward but can be adjusted
>  steady_clock = always goes forward and cannot be adjusted
>  high_resolution_clock = steady_clock || system_clock

+1. This seems like an ideal case for following prior art in designing
a Python API.

Paul
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 418: Add monotonic clock

Glyph Lefkowitz
In reply to this post by zooko
On Mar 26, 2012, at 10:26 PM, Zooko Wilcox-O'Hearn wrote:

Note that the C++ standard deprecated monotonic_clock once they
realized that there is absolutely no point in having a clock that
jumps forward but not back, and that none of the operating systems
implement such a thing -- instead they all implement a clock which
doesn't jump in either direction.

This is why I don't like the C++ terminology, because it seems to me that the C++ standard makes incorrect assertions about platform behavior, and apparently they standardized it without actually checking on platform capabilities.

The clock does jump forward when the system suspends.  At least some existing implementations of steady_clock in C++ already have this problem, and I think they all might.  I don't think they can fully fix it without kernel changes, either.  On linux, see discussion of a possible CLOCK_BOOTTIME in the future.  The only current way I know of to figure out how long the system has been asleep is to look at the wall clock and compare, and we've already gone over the problems with relying on the wall clock.

Plus, libstdc++ gives you no portable way to get informed about system power management events, so you can't fix it even if you know about this problem, natch.

Time with respect to power management state changes is something that the PEP should address fully, for each platform.

On the other hand, hopefully you aren't controlling your python-based CNC laser welder from a laptop that you are closing the lid on while the beam is in operation.  Not that the PEP shouldn't address it, but maybe it should just address it to say "you're on your own" and refer to a few platform-specific resources for correcting this type of discrepancy.  (<https://developer.apple.com/library/mac/#qa/qa1340/_index.html>, <http://msdn.microsoft.com/en-us/library/aa394362.aspx>, <http://upower.freedesktop.org/docs/UPower.html#UPower::Sleeping>).

-glyph


_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 418: Add monotonic clock

Glyph Lefkowitz
On Mar 27, 2012, at 3:17 AM, Glyph wrote:

I don't think they can fully fix it without kernel changes

I got really curious about this and went and did some research.  With some really platform-specific hackery on every platform, you can mostly figure it out; completely on OS X and Windows, although (as far as I can tell) only partially on Linux and FreeBSD.

I'm not sure if it's possible to make use of these facilities without a Twisted-style event-loop though.  If anybody's interested, I recorded the results of my research in a comment on the Twisted ticket for this: <http://twistedmatrix.com/trac/ticket/2424#comment:26>.

-glyph

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 418: Add monotonic clock

Lennart Regebro-2
Reading this discussion, my conclusion is that not only us are
confused, but everyone is. I think therefore, that the way forward is
to only expose underlying API functions, and pretty much have no
intelligence at all.

At a higher level, we have two different "desires" here. You may want
a monotonic clock, or you may not care. You may want high resolution,
or you might not care. Which one is more important is something only
you know. Therefore, we must have, at the minimum, a function that
returns the highest resolution monotonic clock possible, as well as a
function that returns the highest resolution system/wall clock
possible. We also need ways to figure out what the resolution is of
these clocks.

In addition to that, you may have the requirement that the monotonic
clock also should not be able to jump forward, but if I understand
things correctly, most current OS's will not guarantee this. You may
also have the requirement that the clock not only does not jump
forward, but that it doesn't go faster or slower. Some clock
implementations will speed up or slow down the monotonic clock,
without jumps, to sync up with the wall clock. It seems only Unix
provides a monotonic clock (CLOCK_MONOTONIC_RAW) that does not get
adjusted at all.

Now between all these requirements, only you know which one is more
important? Do you primarily want a raw monotonic clock, and
secondarily high resolution, or is the resolution more important than
it being monotonic? (Because if you need a high resolution, you are
usually measuring small timeframes, and the clock is more unlikely to
be adjusted, for example).

Since there is no obvious "A is better than B that is better than C"
we first of all have to expose the underlying API's somehow, to allow
people to make their own decisions. Secondly, since apparently not
only python-dev, but many others as well, are a bit confused on this
complex issue, I'm not sure we can provide any high-level functions
that makes a best choice.

As such the proposed time.monotonic() to get the monotonic clock on
the various systems makes a lot of sense to me. It should get the
highest resolution available on the system. Get GetTickCount64() of
available on Windows, else GetTickCount(). The function could have a
raw=False parameter to select between clock_gettime(CLOCK_MONOTONIC)
and clock_gettime(CLOCK_MONOTONIC_RAW) on Unix, and it would get
mach_absolute_time() on OS X.

If no monotonic clock is available, it should raise an error.The same
if you pass in raw=True and there is no monotonic clock that has no
adjustments available.

In the same vein, time.time() should provide the highest resolution
system clock/wall clock available.

We also need functions or attributes to get the resolution of these clocks.


But a time.steady() that tries to get a "best case" doesn't make sense
at this time, as apparently nobody knows what a best case is, or what
it should be called, except that it should apparently not be called
steady(). Since monotonic() raises an error if there is no monotonic
clock available, implementing your own fallback is trivial in any
case.

//Lennart
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 418: Add monotonic clock

Nick Coghlan
On Tue, Mar 27, 2012 at 7:03 PM, Lennart Regebro <[hidden email]> wrote:
> But a time.steady() that tries to get a "best case" doesn't make sense
> at this time, as apparently nobody knows what a best case is, or what
> it should be called, except that it should apparently not be called
> steady(). Since monotonic() raises an error if there is no monotonic
> clock available, implementing your own fallback is trivial in any
> case.

+1 from me to Lennart's suggestion of mostly just exposing
time.monotonic() without trying to get too clever. Applications that
need a truly precise time source should *never* be reading it from the
host OS (one fairly good solution can be to read your time directly
from an attached GPS device).

However, I think Victor's right to point out that the *standard
library* needs to have a fallback to maintain backwards compatibility
if time.monotonic() isn't available, and it seems silly to implement
the same fallback logic in every module where we manipulate timeouts.
As I concur with others that time.steady() is a thoroughly misleading
name for this concept, I suggest we encapsulate the "time.monotic if
available, time.time otherwise" handling as a "time.try_monotic()"
function.

That's simple clear and explicit: try_monotic() tries to use the
monotic clock if it can, but falls back to time.time() rather than
failing entirely if no monotonic clock is available. This is essential
for backwards compatibility when migrating any current use of
time.time() over to time.monotic(). Yes the monotonic clock is
*better* for many use cases (including timeouts), but you'll usually
be OK with the non-monotonic clock, too (particularly if that's what
you were using anyway in earlier versions). After all, we've survived
this long using time.time() for our timeout calculations, and bugs
associated with clock adjustments are a rather rare occurrence.

Third party libraries that need to support earlier Python versions can
then implementation their own fallback logic (since they couldn't rely
on time.try_monotonic being available either).

The 3.3 time module would then be left with three interfaces:

time.time() # Highest resolution timer available
time.monotonic() # I'm not yet convinced we need the "raw" parameter
but don't much mind either way
time.try_monotonic() # Monotonic is preferred, but non-monotonic
presents a tolerable risk

Regards,
Nick.

--
Nick Coghlan   |   [hidden email]   |   Brisbane, Australia
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 418: Add monotonic clock

Ethan Furman-2
Nick Coghlan wrote:
> The 3.3 time module would then be left with three interfaces:
>
> time.time() # Highest resolution timer available
> time.monotonic() # I'm not yet convinced we need the "raw" parameter
> but don't much mind either way
> time.try_monotonic() # Monotonic is preferred, but non-monotonic
> presents a tolerable risk

+1

~Ethan~
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 418: Add monotonic clock

Yury Selivanov-2
In reply to this post by Nick Coghlan
On 2012-03-27, at 9:23 AM, Nick Coghlan wrote:

> time.try_monotonic() # Monotonic is preferred, but non-monotonic
> presents a tolerable risk

This function seems unnecessary.  It's easy to implement it when
required in your application, hence I don't think it is worth
adding to the stdlib.

-
Yury
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 418: Add monotonic clock

Victor Stinner-3
In reply to this post by Victor Stinner-3
> I started to write the PEP 418 to clarify the notions of monotonic and
> steady clocks.

I replaced time.steady() by time.try_monotonic(). I misunderstood "may
not" in the C++ doc: I understood it as "it may be adjusted by NTP",
whereas it means "it cannot be adjusted". Sorry for the confusion.

I added a time.hires() clock because time.monotonic() and
time.try_monotonic() are not the best clocks for profiling or
benchmarking. For example, on Windows, time.hires() uses
QueryPerformanceCounter() whereas time.monotonic() and
time.try_monotonic() uses GetTickCount[64]().

I added the pseudo-code of each function. I hope that it is easier to
understand than a long text.

Victor
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 418: Add monotonic clock

Ethan Furman-2
In reply to this post by Yury Selivanov-2
Yury Selivanov wrote:
> On 2012-03-27, at 9:23 AM, Nick Coghlan wrote:
>
>> time.try_monotonic() # Monotonic is preferred, but non-monotonic
>> presents a tolerable risk
>
> This function seems unnecessary.  It's easy to implement it when
> required in your application, hence I don't think it is worth
> adding to the stdlib.

If I understood Nick correctly, time.try_monotonic() is /for/ the
stdlib.  If others want to make use of it, fine.  If others want to make
their own fallback mechanism, also fine.

~Ethan~
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 418: Add monotonic clock

Victor Stinner-3
In reply to this post by Scott Dial
> What is the utility of "strict=True"? If I wanted that mode of
> operation, then why would I not just try to use "time.monotonic()"
> directly?

I mentioned the strict=True API in the PEP just to list all
propositions, but the PEP only proposes time.monotonic() and
time.try_monotonic(), no the flags API.

> At worst, it generates an "AttributeError" (although that is not clear from your PEP).

I tried to mention when a function is always available or not always
available. Is it better in the last version of the PEP?

>  system_clock = wall clock time
>  monotonic_clock = always goes forward but can be adjusted
>  steady_clock = always goes forward and cannot be adjusted
>  high_resolution_clock = steady_clock || system_clock

I tried to follow these names in the PEP. I don't propose steady_clock
because I don't see exactly which clocks would be used to implement
it, nor if we need to provide monotonic *and* steady clocks. What do
you think?

> Straying from that is only going to create confusion. Besides that, the
> one use case for "time.steady()" that you give (benchmarking) is better
> served by a clock that follows the C++0x definition.

I added a time.hires() clock to the PEP for the benchmarking/profiling
use case. This function is not always available and so a program has
to fallback manually to another clock. I don't think that it is an
issue: Python programs already have to choose between time.clock() and
time.time() depending on the OS (e.g. timeit module and pybench
program).

> As well, certain
> kinds of scheduling/timeouts would be better implemented with the C++0x
> definition for "steady" rather than the "monotonic" one and vice-versa.

Sorry, I don't understand. Which kind of scheduling/timeouts?

The PEP is still a draft (work-in-progress).

Victor
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 418: Add monotonic clock

Victor Stinner-3
In reply to this post by Scott Dial
> steady_clock:
>
>  mac = mach_absolute_time
>  posix = clock_gettime(CLOCK_MONOTONIC)
>  win = QueryPerformanceCounter

I read that QueryPerformanceCounter is no so monotonic, and
GetTickCount is preferred. Is it true?

> high_resolution_clock:
>
>  * = { steady_clock, if available
>        system_clock, otherwise }

On Windows, I propose to use QueryPerformanceCounter() for
time.hires() and GetTickCount() for time.monotonic().

See the PEP for other OSes.

Victor
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
1234 ... 8