time.clock() going backwards??

[K.S.Sreeram]

Giovanni Bajo wrote:
> 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)?

From the MSDN docs for QueryPerformanceCounter:

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.

Are you running on a multi-core or a multi-processor machine?

The best way to handle this is probably to make your application
'tolerant' to such cases.

[sreeram;]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-list/attachments/20060825/90e0753f/attachment.sig>