Anomaly in time.clock()

[Godzilla]

Hello,

I have been reading a thread about time.clock() going backward, which
is exactly what I am seeing... the thread generally leaning toward the
problem is caused by multi-processor machines. But I am seeing it at a
single CPU computer, and running XP.

The error I am seeing between two very close invokation of
time.clock() is always around 3.5 seconds! This is enough to throw a
lot of the timing requirement in the software out of the window...
this is a fairly serious problem. A quick fix will be to capture the
time.clock() going backward 3.5 seconds, and then adjust rest of the
system accordingly. But I don't feel like this is a good way around
this problem. I was using time.time() before switching to
time.clock(). The reason I changed is because I need a way to
calculate elapsed time independent of system time.

Should I just stick with time.time() instead? Or is there another way
to calculate elapsed time accurately, independent of system time being
changed?

[Roel Schroeven]

Godzilla schreef:

Hello,

I have been reading a thread about time.clock() going backward, which
is exactly what I am seeing... the thread generally leaning toward the
problem is caused by multi-processor machines. But I am seeing it at a
single CPU computer, and running XP.

The error I am seeing between two very close invokation of
time.clock() is always around 3.5 seconds! This is enough to throw a
lot of the timing requirement in the software out of the window...
this is a fairly serious problem.

I don't know if it's the same problem, but I've seen something similar
to this. Are you by any chance using DirectX? When you create a DirectX
device, DirectX by default resets the precision of the CPU to 20 bits or so.

I had that problem in a project at work, with similar results (and other
strange calculation errors). The solution was to use a flag
(PRESERVE_PRECISION or something like that) in the CreateDevice() call
(it was a C++ project).

If it's something else, I'm afraid I can't help.

--
The saddest aspect of life right now is that science gathers knowledge
faster than society gathers wisdom.
-- Isaac Asimov

Roel Schroeven

[Ross Ridge]

Godzilla <go***********@gmail.comwrote:

>But the time.clock() sometimes return a value of between -3.5 to -4.5
seconds backward.

There are race conditions in your code. In between the time you execute
"curTime = time.clock()" and calculate "curTime - self.timeStamp" in one
thread, the other thread can execute "self.timeStamp = time.clock()".
It's the only way your example program can print a negative "Actual
Elapsed Time" value. The race condition seems unlikely, and it's hard
to explain how this could result in it printing a value in the range
of -3.5 to -4.5. However, a race condition occuring between the two
evaluations of "curTime - self.timeStamp" is the only way your example
program could print a negative value.

Ross Ridge

--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rr****@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //

[John Machin]

On Mar 19, 11:17 pm, Godzilla <[e-mail]:

Hi John,

I am using time.clock to calculate the elapsed time. Below is an
example of what I was trying to do:

import time
import thread

Silly me, not being able to infer that from your initial post!

[snip]

>
But the time.clock() sometimes return a value of between -3.5 to -4.5
seconds backward. Note that not all computers are behaving the same. I
have not experience the same problem with the computer at home.

Same "service pack" number?

Your code "worked" (no time warp) for me on a single-core AMD Turion64
CPU running (32 bit) Windows XP Service Pack 2 Build 2600. Maybe the
ones that "fail" have dual-core CPUs.

[Godzilla]

Just found out that win32api.GetTickCount() returns a tick count in
milli-second since XP started. Not sure whether that is reliable.
Anyone uses that for calculating elapsed time?

[Gabriel Genellina]

On 21 mar, 03:13, Godzilla <[e-mail]:

Just found out that win32api.GetTickCount() returns a tick count in
milli-second since XP started. Not sure whether that is reliable.
Anyone uses that for calculating elapsed time?

I use GetTickCount on other languages because it's easy to call. Note
that it returns a value in ms but the *precision* may be not so high.
Anyway I think your problem is in the code, not on time.clock()

--
Gabriel Genellina

[Tim Roberts]

Godzilla <go***********@gmail.comwrote:

>
Just found out that win32api.GetTickCount() returns a tick count in
milli-second since XP started. Not sure whether that is reliable.
Anyone uses that for calculating elapsed time?

What do you mean by "reliable"? The tick count is updated as part of
scheduling during timer interrupts. As long as no one disables interrupts
for more than about 15ms, it is reliable.

However, it's only a 32-bit value, so the number rolls over every 49 days.
--
Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.

[Craig]

On Mar 22, 10:03 pm, Tim Roberts <[e-mail]:

Godzilla <[e-mail]:

Just found out that win32api.GetTickCount() returns a tick count in
milli-second since XP started. Not sure whether that is reliable.
Anyone uses that for calculating elapsed time?

What do you mean by "reliable"? The tick count is updated as part of
scheduling during timer interrupts. As long as no one disables interrupts
for more than about 15ms, it is reliable.

However, it's only a 32-bit value, so the number rolls over every 49 days.
--
Tim Roberts, [e-mail]
Providenza & Boekelheide, Inc.

Try getting XP or Vista to stay up for 49 days. I have had Vista stay
up for a little over 11 days. If it doesn't crash, it will have to be
rebooted for some update or other.