next up previous
Next: Future plans Up: Interrupts Previous: How to program and

 

Interrupts and Linux (Interrupt latency)

Linux is no RTOS (even with its POSIX extensions like sched_setscheduler()), so it gives no guarantees for response on interrupts. On a complete idle system, the device drivers interrupt handler will be called in 2 us, but on a well loaded system you have up to 600us. You may say, that even this worst case is enough for you, but the real story is another one. Your user process will be informed of the pending interrupt by signal (SIGUSR1), and will process it (via its signal handler) at the next scheduling. So on a well loaded system (hogging CPU, much I/O) your process will catch the pending interrupt about a time of hundreds of ms later! This can be too much, above all in the case of RORA/ArwvmeRoraByUser (which means, that during this time you may miss some interrupts). There is a solution called RTLinux (its a RTOS kernel running Linux as its idle task), which makes guarantees of schedule times with an accuracy of 35us. But its API is not compatible with standard Linux device driver writing. Any data exchange of such a driver (its really a module) is done via fifos, which are devices to the user process. So you had to rewrite the driver completely, and it would never be a normal Linux driver. Such a solution is excellent for device drivers with specific and limited features (like a frame grabber). So your only way out (in the case of ArwvmeRoraByUser) is to use sched_setscheduler with SCHED_RR (be gentle) for your user process, and hope it will be enough for your task. I have tested this solution with heavy load and measured worst cases of 10ms (which is exactly the interrupt frequency of the clock) until the user process get informed. You can not get better with this extension! To really get better, you have to use another clock with increased interrupt frequency or use a variable programmed clock. For the sake of fairness, without sched_setscheduler() you may get worst cases of 1s, so it is a tremendous improvement given by the POSIX RT extensions, but it will be smoked by RTLinux. Another way out is to extend the device driver (by using rt_request_irq) and do whatever has to be done now at this place, exchanging the data via rt_fifos.


next up previous
Next: Future plans Up: Interrupts Previous: How to program and


Fri Jul 2 08:09:45 MEST 1999