> On 9 Maj, 03:23, John Nagle <[EMAIL PROTECTED]> wrote: > > Hendrik van Rooyen wrote: > > > "Tim Roberts" <[EMAIL PROTECTED]> wrote" > > > It is also possible to keep the timer list sorted by "expiry date", > > > and to reprogram the timer to interrupt at the next expiry time > > > to give arbitrary resolution, instead of implementing a regular 'tick'. > > > > Yes, and that's a common feature in real-time operating systems. > > If you're running QNX, you can expect that if your high priority > > task delays to a given time, you WILL get control back within a > > millisecond of the scheduled time. Even tighter timing control > > is available on some non-x86 processors. > > > > Some CPUs even have hardware support for a sorted event list. > > The Intel 8061, which ran the engines of most Ford cars in the 1980s, > > had that. > > > > But no way are you going to get consistent timing resolution like that > > from Python. It's an interpreter with a garbage collector, after all. > > > > John Nagle > > > The application the original poster (i.e. me) was interested in was a > program that sends ethernet packets at a loosely specified rate. A > loop that sends all packets with no sleep in between will send them at > a too high rate. Using the default sleep in my Python interpreter > sleeps to long, since even a few microseconds add up when you send > hundreds of thousands of packets. > > If the process scheduler deals with another process now and then, it > doesn't matter. If it switches to another application between each > packet is beeing sent, that's a problem. > > Anyways, what I need is high resolution sleep, not high resolution > timing. Installing a real time OS seems like overkill. > > (Yes I know, one can also send, say, 50 packets at a time, and then > sleep, send 50 more packets, and so on.) > > -- > http://mail.python.org/mailman/listinfo/python-list
What about C module with usleep,nanosleep? Best regards. Bart. -- http://mail.python.org/mailman/listinfo/python-list