Messages in this thread | | | Date | Sun, 04 Jul 1999 23:12:32 -0700 | From | Dong Liu <> | Subject | Re: Can't sleep less than 20 ms |
| |
Rogier Wolff wrote: > > Dong Liu wrote: > > Boussard Per wrote: > > > > > > On Fri, 2 Jul 1999, Andrea Arcangeli wrote: > > > > > > > > > > > Set the policy of the scheduler as RT. > > > > > > > > > > This will only work for root, no? The problem is the tv_sec||tv_nsec > > > expression in sys_nanosleep(). I think this must go. > > > > This seems to be correct, I changed > > > > expire = timespec_to_jiffies(&t) + (t.tv_sec || t.tv_nsec); > > to > > expire = timespec_to_jiffies(&t); > > > > in sys_nanosleep(), now I got > > > > usleep ( <=10*1000) sleeps for 10 ms > > usleep ( >10*1000 <= 20*1000) sleeps for 20 ms > > usleep ( >20*1000 <= 30*1000) sleeps for 30 ms > > This may be a nice hack for YOU, but in no way should this be in the > standard kernel. > > This looks fine: > > Clock interrupts + + + + + > App is waken up: * * * * > app calls usleep (9000) ^ ^ ^ ^ > > but... if the application uses 8ms of CPU time before calling > usleep again: > > Clock interrupts + + + + + > App is waken up: * * * * > app calls usleep (9000) ^ ^ ^ ^ > > it will only sleep for 2ms before getting woken. And the manual states > that the sleep will be -=* at least *=- the number of microseconds > requested, and that you should always be prepared to be woken a little > later due to scheduling overhead or other tasks running. >
I already have a solution for this, I'll have one thread sleep for exact 10ms and then post an event, another thread will do the processing (I'm writing a RTP library, I have to send/recieve RTP packets in the right interval) then wait for the event. In this way, the processing thread will wake up at the moment of (10ms - the time used to do processing).
Increasing HZ maybe another solution. but I don't the performance implication.
Dong
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |