Anomaly in time.clock()

Godzilla godzillaismad at gmail.com
Mon Mar 17 07:26:56 EDT 2008


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?



More information about the Python-list mailing list