Lots of people hear “Low-Latency”, say “Woohoo!” and run to recompile their Linux kernel…

…only to discover, with great dismay, that their PC’s overall performance just dropped to the floor. Bum!

Here’s why, folks!

Graph showing low-latency changes

In the first timeline we have some inputs.

  • They have a certain priority
  • One of them (painted in orange) requires a real-time answer (the answer is not valid if it comes too late)
  • There is no way to predict inputs (otherwise the inputs would have been ordered as so: RT – 2 – 1 – 0)
  • Every input triggers a task that requires 4 CPU cycles to be executed
  • The CPU context switch is done in 1 cycle.

In the second timeline we have a FIFO (First In First Out) scheduling that guarantees high throughput.

  • Context switches (painted in blue) occur with low frequency
  • Every job is done at full speed
  • All jobs are done in a small amount of time
  • But: the real-time input received a high latency (the answer came too late)
  • Conclusion: this scheduling is not really suitable for a desktop environment, absolutely not when there are hard real-time requirements
    • Audio/video applications require lower latencies.
    • The PC seems less responsive to user inputs even if it’s doing all his tasks in the smallest time.

In the third timeline we have a low-latency scheduling.

  • Context switches are more frequent
  • The real-time input has received a low latency and its task is executed before the completion of red and yellow tasks.
  • But: the overall performance is worse (it takes more time to finish all the jobs)
  • Conclusion: this scheduling is not suitable for a server environment
    • Some tasks might never be finished if their priority is low
    • The red task is done in a very long time (usually on a server tasks have similar priorities)

So what am I trying to say?

  • If you’re doing professional audio/video editing, or are building up a “media center”, then a low-latency kernel might be good for you.
    • Have a look at Ingo Molnar’s “Realtime-Preemption” patches
    • Be ready to have more cups of coffee while your low-latency system builds another kernel
    • You won’t lose a single DVD frame and your wobbly windows will be really wobbly :o )
  • If you’re building a HARD real-time system, then you need something more than a different scheduler.
    • You may be interested in the RTAI patch
    • Get a DVD player and forget about wobbly windows
  • If you simply want a more responsive desktop system without degrading overall performance, then Con Kolivas’ patches do the job.
    • Beware! The kernel must be 2.6.22 or lower! Con Kolivas is not doing new patches.
    • It makes an intensive use of swap memory: your HD will work a lot
    • There is a server version, too
  • If you’re building a server system, then the “vanilla” kernel compiled with a “Timer Frequency” value set to 100Hz is OK.
    • In the worst case you’ll have a context switch only every 0.01 sec. (for maximum throughput).
    • Desktop PCs usually do a context switch every 0.001 sec. (medium throughput, better responsiveness).