-Original Message-
From: gvanros...@gmail.com [mailto:gvanros...@gmail.com] On Behalf
Of Guido van Rossum
Sent: 2. apríl 2012 17:43
To: Kristján Valur Jónsson
Cc: Cameron Simpson; Python Dev
Subject: Re: [Python-Dev] Use QueryPerformanceCounter() for
time.monotonic
You seem to have missed the episode where I explained that caching the last
value in order to avoid going backwards doesn't work -- at least not if the
cached value is internal to the API implementation.
Yes, and I can't find it by briefly searching my mail. I haven't had the
energy to
Victor Stinner wrote:
You seem to have missed the episode where I explained that caching the last
value in order to avoid going backwards doesn't work -- at least not if the
cached value is internal to the API implementation.
Yes, and I can't find it by briefly searching my mail. I haven't
-Original Message-
From: python-dev-bounces+kristjan=ccpgames@python.org
Some years? I computed 584.5 years, so it should not occur in practice.
Funny that you mention it. should not occur in practice is exactly my point.
Here's actual code from production:
BOOL WINAPI
On 30 March 2012 21:52, Guido van Rossum gu...@python.org wrote:
Oh dear. I really want to say that 15 ms is good enough. Some possible
exceptions I can think of:
- Profiling. But this really wants to measure CPU time anyways, and it
already uses a variety of hacks and heuristics to pick the
On Mon, Apr 2, 2012 at 2:31 AM, Sam Partington sam.parting...@gmail.com wrote:
On 30 March 2012 21:52, Guido van Rossum gu...@python.org wrote:
Oh dear. I really want to say that 15 ms is good enough. Some possible
exceptions I can think of:
- Profiling. But this really wants to measure CPU
At least on some versions of Windows (e.g. XP) the
QueryPerformanceCounter()-API is more or less only a stub around a
call to RDTSC which in turn varies in frequency on (at least) Intel
Pentium 4, Pentium M and Xeon processors (bound to the current clock
frequencies).
-Original Message-
From: python-dev-bounces+kristjan=ccpgames@python.org
[mailto:python-dev-bounces+kristjan=ccpgames@python.org] On
Behalf Of Cameron Simpson
Sent: 30. mars 2012 21:43
There seem to be a few competing features for clocks that people want:
- monotonic -
You seem to have missed the episode where I explained that caching the
last value in order to avoid going backwards doesn't work -- at least
not if the cached value is internal to the API implementation.
2012/4/2 Kristján Valur Jónsson krist...@ccpgames.com:
-Original Message-
From:
On Apr 2, 2012, at 10:39 AM, Kristján Valur Jónsson wrote:
no steps is something unquantifiable. All time has steps in it.
No steps means something very specific when referring to time APIs. As I
recently explained here:
http://article.gmane.org/gmane.comp.python.devel/131487/.
-glyph
On Sat, Mar 31, 2012 at 8:46 AM, Guido van Rossum gu...@python.org wrote:
Given the amount of disagreement I sense, I think we'll need to wait
for more people to chime in.
I currently can't imagine why I *personally* would want anything
better than what we currently call time.time. For that
On 03/31/2012 12:47 AM, Victor Stinner wrote:
Can you go into more detail about QPC()'s issues?
Yes, see the PEP:
http://www.python.org/dev/peps/pep-0418/#windows-queryperformancecounter
FYI, Victor, the PEP is slightly incomplete. Not that this is your
fault--you've done your homework.
FYI, Victor, the PEP is slightly incomplete.
Sure. What should be added to the PEP?
But there's another problem: the TSC frequency actually *does*
change when SpeedStep kicks in. I know someone who complained bitterly
about running Half-Life 2 on their shiny new laptop, and when it'd
If we provide a way to check if the monotonic clock is monotonic (or
not), I agree to drop the flag from time.monotonic(fallback=True) and
always fallback. I was never a fan of the truly monotonic clock.
time.clock_info('monotonic')['is_monotonic'] is a good candidate to
store this
On Sat, Mar 31, 2012 at 7:37 PM, Victor Stinner
victor.stin...@gmail.com wrote:
If we provide a way to check if the monotonic clock is monotonic (or
not), I agree to drop the flag from time.monotonic(fallback=True) and
always fallback. I was never a fan of the truly monotonic clock.
On Fri, Mar 30, 2012 at 1:21 PM, Victor Stinner
victor.stin...@gmail.com wrote:
Windows provides two main monotonic clocks: QueryPerformanceCounter()
and GetTickCount(). QueryPerformanceCounter() has a good accuracy (0.3
ns - 5 ns) but has various issues and is know to not have a steady
rate.
On Fri, Mar 30, 2012 at 1:52 PM, Guido van Rossum gu...@python.org wrote:
On Fri, Mar 30, 2012 at 1:21 PM, Victor Stinner
victor.stin...@gmail.com wrote:
Windows provides two main monotonic clocks: QueryPerformanceCounter()
and GetTickCount(). QueryPerformanceCounter() has a good accuracy (0.3
Possibly we really do need two timers, one for measuring short
intervals and one for measuring long intervals? Perhaps we can use
this to decide on the names?
Anyway, the more I think about it, the more I believe these functions
should have very loose guarantees, and instead just cater to common
On 30Mar2012 13:52, Guido van Rossum gu...@python.org wrote:
| (In fact, this even argues against having both the timer with fallback
| and the timer without fallback. So maybe we should just have a single
| timer function, *with* fallback, and a separate mechanism to inquire
| its properties.)
On Fri, Mar 30, 2012 at 2:43 PM, Cameron Simpson c...@zip.com.au wrote:
On 30Mar2012 13:52, Guido van Rossum gu...@python.org wrote:
| (In fact, this even argues against having both the timer with fallback
| and the timer without fallback. So maybe we should just have a single
| timer
Can you go into more detail about QPC()'s issues?
Yes, see the PEP:
http://www.python.org/dev/peps/pep-0418/#windows-queryperformancecounter
What is unsteady about its rate?
Hum, I read that you can expect a drift between QPC and GetTickCount.
I don't have exact numbers. There are also issues
On 30Mar2012 15:21, Guido van Rossum gu...@python.org wrote:
| On Fri, Mar 30, 2012 at 2:43 PM, Cameron Simpson c...@zip.com.au wrote:
| Given the subtlety sought for various purposes, people should be
| calling:
| T = time.getclock(flags)
| and then later calling:
| T.now()
| to get their
Given the amount of disagreement I sense, I think we'll need to wait
for more people to chime in.
On Fri, Mar 30, 2012 at 3:47 PM, Victor Stinner
victor.stin...@gmail.com wrote:
Can you go into more detail about QPC()'s issues?
Yes, see the PEP:
On Fri, Mar 30, 2012 at 4:44 PM, Cameron Simpson c...@zip.com.au wrote:
[Lots of good stuff]
Maybe you and Victor should try to merge your proposals off-line and
then get back with a new proposal here.
Make the epoch available in the clock wrapper as a property. At least
then there's a
2012/3/31 Guido van Rossum gu...@python.org:
Given the amount of disagreement I sense, I think we'll need to wait
for more people to chime in.
I hope that the PEP now gives enough data to help to choose the best API.
Hum, I read that you can expect a drift between QPC and GetTickCount.
I
On Mar 30, 2012, at 8:51 PM, Victor Stinner wrote:
time.highres() (QPC) rate is only steady during a short duration
QPC is not even necessarily steady for a short duration, due to BIOS bugs,
unless the code running your timer is bound to a single CPU core.
There seem to be a few competing features for clocks that people want:
- monotonic - never going backward at all
- high resolution
These features look to be exclusive on Windows. On other platforms, it
looks like monotonic clocks are always the most accurate clocks. So I
don't think that we
On Fri, Mar 30, 2012 at 5:51 PM, Victor Stinner
victor.stin...@gmail.com wrote:
2012/3/31 Guido van Rossum gu...@python.org:
Given the amount of disagreement I sense, I think we'll need to wait
for more people to chime in.
I hope that the PEP now gives enough data to help to choose the best
On Fri, Mar 30, 2012 at 6:24 PM, Victor Stinner
victor.stin...@gmail.com wrote:
There seem to be a few competing features for clocks that people want:
- monotonic - never going backward at all
- high resolution
These features look to be exclusive on Windows. On other platforms, it
looks
On Mar 30, 2012, at 9:32 PM, Guido van Rossum wrote:
- no steps
You mean not adjusted by NTP? Except CLOCK_MONOTONIC on Linux, no
monotonic clock is adjusted by NTP. On Linux, there is
CLOCK_MONOTONIC_RAW, but it is only available on recent Linux kernel
(2.6.28).
Do you think that it
Impact: A timeout may be 42 seconds shorter than the requested
duration if is uses QPC. For a scheduler, a task would be scheduled at
the right moment.
I don't understand this paragraph. And why is it always exactly a loss
of 42 seconds?
Sorry, it's late here, I'm too tired. A jump of 42
(...)
By contrast, stepping only happens if your local clock is just set
incorrectly and the re-sync delta has more to do with administrative error
or failed batteries than differences in timekeeping accuracy.
Are you talking about CLOCK_REALTIME or CLOCK_MONOTONIC?
Victor
On Mar 30, 2012, at 10:17 PM, Victor Stinner wrote:
(...)
By contrast, stepping only happens if your local clock is just set
incorrectly and the re-sync delta has more to do with administrative error
or failed batteries than differences in timekeeping accuracy.
Are you talking about
On Mar 30, 2012, at 10:25 PM, Glyph wrote:
On Mar 30, 2012, at 10:17 PM, Victor Stinner wrote:
(...)
By contrast, stepping only happens if your local clock is just set
incorrectly and the re-sync delta has more to do with administrative error
or failed batteries than differences in
34 matches
Mail list logo
