At 02:59 AM 8/4/2006, Gabriel Genellina wrote: >I'm not sure if this really works, but you could try: >- Raise your thread/process's priority using SetPriorityClass or >SetThreadPriority. This is to minimize the (unpredictable) delay of sleep()
I do launch the module with CreateProcess with RealTimePriority - it does stabilize things a bit >- Keep your qPC loop, but insert a sleep(0) call, this would free the CPU. Does 0 have a special meaning vs. .0000001 for example? I'll give it a try. The desired total delay is about .0056s, so I'd like to sleep() for ~.004 and then wake up and catch the exact tick. For some reason, sleep(.001) actually adds up to a good bit more, like .004, and sleep(.0001) collapses to ~statement execution time, like 10us! That's why if I use .0001 the CPU is still 100% loaded; with .001 it drops to near zero, but, the timing is way off. I'l do an example code to demonstrate, and see if others get the same responses. I'm wondering if sleep() uses the 8254 or RTC timers instead of the TSC counter or APIC timer(?) I did see an interesting point about RTAI as well " Also, one should note that nanosleep() is a busy wait in the kernel when the request to sleep is for an amount of two milliseconds or less. Therefore, a busy wait would not simulate interrupt response time as well as a true sleep. ", so LINUX does not have a true short sleep() either... http://www.rtems.com/ml/rtems-users/2004/march/msg00067.html has a good discussion as well that I need to look into. Thanks, Ray _______________________________________________ Python-win32 mailing list Python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
