[python-win32] sleep() for less than .001s?

[RayS]

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