time.clock() or Windows bug?

[Nick Craig-Wood]

Theo v. Werkhoven <theo at van-werkhoven.nl.invalid> wrote:
>  In this code I read out an instrument during a user determined period,
>  and save the relative time of the sample (since the start of the test)
>  and the readback value in a csv file.
> 
>  from datetime import *
>  from time import *
>  from visa import *
>  from random import *
>  [..]
>  for Reading in range(Readings):
>     RelTimeOfSample = "%.1f" % clock()
>     #PwrMtr.write("READ?")
>     #Sample = "%.3f" % float(PwrMtr.read())
>     Sample = "%.3f" % (uniform(8.9,9.3))        # Simulation of reading.
>     print "Sample %s, at %s seconds from start; Output power is: %s dBm"
>          % (Reading+1, RelTimeOfSample, Sample)
>     writer.writerow([RelTimeOfSample, Sample])
>     ResultFile.flush()
>     sleep(6.6)
> 
>  Output:
>  Sample 1, at 0.0 seconds from start; Output power is: 8.967 dBm
[snip]
>  Sample 17, at 105.7 seconds from start; Output power is: 9.147 dBm
>  Sample 18, at 112.4 seconds from start; Output power is: 9.284 dBm
>  Sample 19, at 119.0 seconds from start; Output power is: 9.013 dBm
>  Sample 20, at 125.6 seconds from start; Output power is: 8.952 dBm
>  Sample 21, at 91852.8 seconds from start; Output power is: 9.102 dBm
>  Sample 22, at 91862.7 seconds from start; Output power is: 9.289 dBm
>  Sample 23, at 145.4 seconds from start; Output power is: 9.245 dBm
>  Sample 24, at 152.0 seconds from start; Output power is: 8.936 dBm
[snip]
>  But look at the timestamps of samples 21, 22 and 43.
>  What is causing this?
>  I've replaced the time.clock() with time.time(), and that seems to
>  solve the problem, but I would like to know if it's something I
>  misunderstand or if it's a problem with the platform (Windows Server
>  2003) or the time.clock() function.

time.clock() uses QueryPerformanceCounter under windows.  There are
some known problems with that (eg with Dual core AMD processors).

See http://msdn.microsoft.com/en-us/library/ms644904.aspx

And in particular

    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.

I would have said time.time is what you want to use anyway though
because under unix time.clock() returns the elapsed CPU time which is
not what you want at all!

-- 
Nick Craig-Wood <nick at craig-wood.com> -- http://www.craig-wood.com/nick