time.clock() or Windows bug?

[Nick Craig-Wood]

Theo v. Werkhoven <theo at van-werkhoven.nl.invalid> wrote:
>  The carbonbased lifeform Nick Craig-Wood inspired comp.lang.python with:
> > Theo v. Werkhoven <theo at van-werkhoven.nl.invalid> wrote:
> >>  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.
> 
>  Alright, that explains that then.
> 
> > 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!
> 
>  You're right, using fuctions that do not work cross platform isn't
>  smart.

Actually there is one good reason for using time.clock() under Windows
- because it is much higher precision than time.time().  Under Windows
time.time() is only accurate at best 1ms, and in fact it is a lot
worse than that.

Under Win95/98 it has a 55ms granularity and under Vista time().time()
changes in 15ms or 16ms steps.

Under unix, time.clock() is pretty much useless because it measures
CPU time (with a variable precision, maybe 10ms, maybe 1ms), and
time.time() has a precision of about 1us (exact precision depending on
lots of things!).

"""
Test timing granularity

Under Vista this produces

C:\>time_test.py
  15000us -  40 times
  16000us -  60 times

Under linux 2.6 this produces

$ python time_test.py
      1us - 100 times

"""

from time import time

granularities = {}

for i in range(100):
    x = time()
    j = 0
    while 1:
        y = time()
        if x != y:
            dt = int(1000000*(y - x)+0.5)
            granularities[dt] = granularities.get(dt, 0) + 1
            break
        j += 1

dts = granularities.keys()
dts.sort()
for dt in dts:
    print "%7dus - %3d times" % (dt, granularities[dt])


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