On Tue, 25 Jan 2005 00:18:44 -0800, Tim Roberts <[EMAIL PROTECTED]> wrote:
>Ray Schumacher <[EMAIL PROTECTED]> wrote: >> >>I have a need for a time.clock() with >0.000016 second (16us) accuracy. >>The sleep() (on Python 2.3, Win32, at least) has a .001s limit. >> >>Are they lower/better on other's platforms? > >You need to be careful about describing what you're seeing here. It is not >that time.clock() is inaccurate. The problem is that the "time.clock()" >statement takes several hundred microseconds to execute. What system are you on? This is 300 mhz P2 and py2.4b1 gcc/mingw generated: >>> from time import clock >>> min(abs(clock()-clock()) for i in xrange(10**5)) 5.8666657725137128e-006 >>> min(abs(clock()-clock()) for i in xrange(10**5)) 5.866665771847579e-006 >>> min(abs(clock()-clock()) for i in xrange(10**5)) 5.8666657700712221e-006 >>> import time >>> min(abs(time.clock()-time.clock()) for i in xrange(10**5)) 7.5428559824786134e-006 >>> min(abs(time.clock()-time.clock()) for i in xrange(10**5)) 7.5428559824786134e-006 >>> min(abs(time.clock()-time.clock()) for i in xrange(10**5)) 7.5428559824786134e-006 Even with the attribute lookup overhead, it's not several hundred microseconds as a *minimum*. But on e.g. win32 you can get preempted for a number of milliseconds. E.g., turn that to a max instead of a min: I see a couple 20-30 ms ones ;-/ >>> max(abs(time.clock()-time.clock()) for i in xrange(10**5)) 0.0085142082264155761 >>> max(abs(time.clock()-time.clock()) for i in xrange(10**5)) 0.0088125700856949152 >>> max(abs(time.clock()-time.clock()) for i in xrange(10**5)) 0.0022125710913769581 >>> max(abs(clock()-clock()) for i in xrange(10**5)) 0.023374472628631793 >>> max(abs(clock()-clock()) for i in xrange(10**5)) 0.030183995400534513 >>> max(abs(clock()-clock()) for i in xrange(10**5)) 0.0017130664056139722 >>> max(abs(clock()-clock()) for i in xrange(10**5)) 0.0070844179680875641 > >>I had also considered forking a thread that would spin a loop checking >>time.clock() and firing the TTL pulse after the appropriate interval, >>but the real, ultimate resolution of time.clock() appears to be >>~.00035s. If I increase process priority to real-time, it is ~.00028s >>The alternative appears to be more C code... > >Are you seriously considering writing a real-time application in Python on >Windows? The ONLY way to get small-integer microsecond responses in >Windows is to write a kernel driver, and even then there are no guarantees. >Windows is NOT a real-time system. If you have an environment where an >unexpected delay of a millisecond or more is going to cause damage, then >you need to redesign your application. For sure. The big requirements picture is missing (not uncommon ;-) Regards, Bengt Richter -- http://mail.python.org/mailman/listinfo/python-list
