time.clock() going backwards??

[Giovanni Bajo]

Hello,

I experimented something very strange, a few days ago. I was debugging an
application at a customer's site, and the problem turned out to be that
time.clock() was going "backwards" , that is it was sometimes (randomically)
returning a floating point value which was "less than" the value returned by
the previous invokation. The computer was a pretty fast one (P4 3Ghz I think,
running Windows XP), and this happened only between very close invokations of
time.clock().

I have triple-verified this, including printing the repr() of the floating
point number and verifying it was really minor than the previous value by a few
microseconds. In other words, I'm absolutely positive that it's not a mistake
on my side, but that time.clock() was really apparently "jumping backward".
This was confusing the hell out of my application, of course, and I just hacked
it so to ignore these bogus reads, and just reading off again. Since the error
was just of a few microseconds, reading time.clock() again produces a number
which was higher than what I had before, and thus OK for my application.

I was wondering if someone had experimented this behaviour before. I tried
googling but to no effect. Is it possible this to be a bug in Python itself
(maybe, shooting at the moon, in the conversion between the 64bit performance
counter and the floating point representation returned by time.clock()), or
could it be a bug in Windows itself or the mother board drivers (buf if so,
wouldn't other application start going mad)?
--
Giovanni Bajo

[Rob Williscroft]

Claudio Grondi wrote in news:ec******** **@newsreader2. netcologne.de in
gmane.comp.pyth on.general:

Tim Roberts wrote:

>"Tim Peters" <ti********@gma il.comwrote:

>>
It is much simpler than that. With a multiprocessor HAL, including
on a dual-core or hyperthreaded system, QueryPerformanc eCounter
returns the raw cycle counter (RDTSC). However, on Windows XP, the
operating system does not synchronize the cycle counters on multiple
processors, and they can be actually be millions of cycles apart.

This was a change from previous systems. On NT4 and Win2000, the
operating actually rewrote the cycle counters on the second (and
beyond) processors to align them to the first processor, so the delta
was usually only a dozen or two cycles. XP does not appear to do
that. I think that is a huge mistake, since it renders
QueryPerforman ceCounter non-monotonic.

How does it come, that processors on same mainboard run at different
speeds? Do they have separate clock-pulse generators?

I don't see any claim above that they run at different speeds, only
that the counters are several million cycles apart, IOW running at the
same speed but with different initial values, or more likely starting
at different times.

For processors that run at (say) 2GHz, several million (say 10 million)
represents a difference of 10e6/2e9 = 0.005 seconds between when the
processors were sufficiently powered up to start counting cycles.

Rob.
--
http://www.victim-prime.dsl.pipex.com/

[Claudio Grondi]

Rob Williscroft wrote:

Claudio Grondi wrote in news:ec******** **@newsreader2. netcologne.de in
gmane.comp.pyth on.general:

>>Tim Roberts wrote:

>>>"Tim Peters" <ti********@gma il.comwrote:

>>>It is much simpler than that. With a multiprocessor HAL, including
on a dual-core or hyperthreaded system, QueryPerformanc eCounter
returns the raw cycle counter (RDTSC). However, on Windows XP, the
operating system does not synchronize the cycle counters on multiple
processors , and they can be actually be millions of cycles apart.

This was a change from previous systems. On NT4 and Win2000, the
operating actually rewrote the cycle counters on the second (and
beyond) processors to align them to the first processor, so the delta
was usually only a dozen or two cycles. XP does not appear to do
that. I think that is a huge mistake, since it renders
QueryPerform anceCounter non-monotonic.

How does it come, that processors on same mainboard run at different
speeds? Do they have separate clock-pulse generators?

I don't see any claim above that they run at different speeds, only
that the counters are several million cycles apart, IOW running at the
same speed but with different initial values, or more likely starting
at different times.

For processors that run at (say) 2GHz, several million (say 10 million)
represents a difference of 10e6/2e9 = 0.005 seconds between when the
processors were sufficiently powered up to start counting cycles.

Rob.

If it were so, than why can't the delta of time between the processors
be set to exact zero?
I assume, that it is known how many cycles adjusting the value will
take, so it could be done exactly ... hmmm ...

Claudio Grondi

[Grant Edwards]

On 2006-08-28, Claudio Grondi <cl************ @freenet.dewrot e:

>I don't see any claim above that they run at different speeds, only
that the counters are several million cycles apart, IOW running at the
same speed but with different initial values, or more likely starting
at different times.

For processors that run at (say) 2GHz, several million (say 10 million)
represents a difference of 10e6/2e9 = 0.005 seconds between when the
processors were sufficiently powered up to start counting cycles.

If it were so, than why can't the delta of time between the processors
be set to exact zero?

This is

I assume, that it is known how many cycles adjusting the value will
take, so it could be done exactly ... hmmm ...

Claudio Grondi

--
Grant Edwards grante Yow! LIFE is a
at never-ending INFORMERCIAL!
visi.com

[Fredrik Lundh]

Claudio Grondi wrote:

If it were so, than why can't the delta of time between the processors
be set to exact zero?

someone just wrote:

>>>This was a change from previous systems. On NT4 and Win2000, the
operating actually rewrote the cycle counters on the second (and
beyond) processors to align them to the first processor, so the delta
was usually only a dozen or two cycles. XP does not appear to do
that. I think that is a huge mistake, since it renders
QueryPerform anceCounter non-monotonic.

so if you really want to know, you may have to ask microsoft.

</F>

[Fredrik Lundh]

so if you really want to know, you may have to ask microsoft.

footnote: judging from

http://support.microsoft.com/?id=896256

this might be related to advanced power management features in XP. that
note also mentions a hotfix for this.

</F>

[Grant Edwards]

On 2006-08-28, Grant Edwards <gr****@visi.co mwrote:

>>For processors that run at (say) 2GHz, several million (say 10
million) represents a difference of 10e6/2e9 = 0.005 seconds
between when the processors were sufficiently powered up to
start counting cycles.

>If it were so, than why can't the delta of time between the
processors be set to exact zero?

This is

Oops. Hit the wrong key. I meant to say:

This is a _Microsoft_Prod uct_. There doesn't have to be a
reason for something to be done in a half-assed manner.

>I assume, that it is known how many cycles adjusting the value
will take, so it could be done exactly

Yup.

--
Grant Edwards grante Yow! People humiliating
at a salami!
visi.com

[Hendrik van Rooyen]

"Grant Edwards" <gr****@visi.co mWrote:

| On 2006-08-28, Grant Edwards <gr****@visi.co mwrote:
|
| >>For processors that run at (say) 2GHz, several million (say 10
| >>million) represents a difference of 10e6/2e9 = 0.005 seconds
| >>between when the processors were sufficiently powered up to
| >>start counting cycles.
| >
| >If it were so, than why can't the delta of time between the
| >processors be set to exact zero?
| >
| This is
|
| Oops. Hit the wrong key. I meant to say:

Thank god! - I know you are not an idiot - and for some minutes you had me
guessing - I was beginning to think that my brain had finally been destroyed by
drink - trying to figure out this enigmatic post... :-)

- Hendrik

8<-----------------

[Ralf Muschall]

Grant Edwards wrote:

This is a _Microsoft_Prod uct_. There doesn't have to be a
reason for something to be done in a half-assed manner.

No, it is a quantum effect. If the energy of a clock has a
lower bound, there must be a nonzero probability for it to
run backwards.

See <93**********@n ews.state.mn.us >

SCNR, Ralf

[Grant Edwards]

On 2006-08-29, Ralf Muschall <rm*******@teco nt.dewrote:

Grant Edwards wrote:

>This is a _Microsoft_Prod uct_. There doesn't have to be a
reason for something to be done in a half-assed manner.

No, it is a quantum effect. If the energy of a clock has a
lower bound, there must be a nonzero probability for it to
run backwards.

See <93**********@n ews.state.mn.us >

Brain... hurts...

--
Grant Edwards grante Yow! JAPAN is a WONDERFUL
at planet -- I wonder if we'll
visi.com ever reach their level of
COMPARATIVE SHOPPING...