Soft Realtime

There are many definitions floating around what soft-realtime is. I'm not an authority on this section, but give the definition used here to prevent any misunderstandings. Under Soft-realtime a system is capable of responding to a certain class of events with a certain statistical probability and an average delay. There is, however, no guarantee of handling every event, nor is there any guarantee for a maximum worst case delay in the system. In this sense every system is a soft realtime system. Of course, the term is used for systems that have enhanced capabilities in this area. In most cases this will mean:

• high-resolution timers
• a high-probability of reacting to a specific class of events. High probability in this sense means 'higher than regular Linux'.
• low average latency, again low relative to regular Linux.

Soft realtime systems are well-suited for cases where quality depends on average response time and delays, like video-conference and sound processing systems, and if the system will not fail or get into a critical state if the one or other event is lost or delayed strongly. Simply speaking, soft-realtime will improve quality of time related processing problems, but will give you no guarantee. So you can't have safety critical events depend on a soft-realtime system. There are multiple implementations of soft-realtime for Linux, starting out at simply running a thread under the SCHED_FIFO or SCHED_RR scheduling policy in standard Linux all the way to the low-latency kernel patches that make the Linux kernel partially preemptive (please no flames...thanks). Soft Realtime variants of Linux include RED Linux, KURT, RK-Linux and the low-latency patch of Ingo Molnar.