If you don't set your process to SCHED_FIFO or SCHED_RR (only possible as root) and give it realtime priority, you can never be sure to wake up in time (see Gilad's message in the thread). >From my understanding, if you recompile the kernel with HZ value higher than 1000, you can use nanosleep or usleep, without all the fancy tricks. But if your kernel runs in 10 msec quanta, you will have to use cpu tight loops or other realtime solutions. In that case you are correct, and select cannot give you delay of less than 10 msec.
Ami On Tue, 2003-11-04 at 15:18, Gilad Ben-Yossef wrote: > On Tuesday 04 November 2003 14:43, Ehud Karni wrote: > > > I tested the select call on various machines. > > 1. It is not accurate enough (2 ms deviations). > > Yes it does, you don't seem to use sched_setscheduler in your test program to > give your proccess real time priority. setpriority only changes the nice > level of the proccess. If you want real time guantees (which you do here) you > need to ask the kernel to subject your proccess to real time scheduling. > > > 2. It can not be used for delays < 10 ms. > > Unless you recompile the kernel, you are correct. > > > > > Here is my solution (my_usleep) embedded in a test program. > > This function has an accuracy of about 1 micro second. > > No it doesn't. Without real time priority the select is not guranteed to wake > up on time. You can easily miss your mark and over sleep. > > Gilad ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
