Theo v. Werkhoven <[EMAIL PROTECTED]> wrote: > The carbonbased lifeform Nick Craig-Wood inspired comp.lang.python with: > > Theo v. Werkhoven <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick -- http://mail.python.org/mailman/listinfo/python-list