is there better 32 clock() timing?

[Bengt Richter]

On Tue, 25 Jan 2005 00:18:44 -0800, Tim Roberts <timr at probo.com> wrote:

>Ray Schumacher <rays at blue-cove.com> 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