“In this whitepaper on Linux Scheduler Latency, Clark Williams of Red Hat Inc. compares the performance of two popular ways to improve kernel Linux preemption latency — the preemption patch pioneered by MontaVista and the low-latency patch pioneered by Ingo Molnar — and discovers that the best approach might be a combination of both.” Read the long article with some benchmarking information at LinuxDevices.
Which is Better? the Preempt Patch or the Low-Latency Patch? Both!
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Lets patch it with the NT kernel. <pokes linux geeks>
Right now there is no OS solution that’s even close to perfect. The answer is neither Linux or Windows.
Define “perfect”. It’s a different thing for everyone.
qnx is close, but not there?
The QNX kernel itself doesn’t hold a candle to the Linux kernel on the desktop. Slow filesystem, not much of a VM to speak of. In fact, anything that comes close to the perfect desktop would have to be based on the Linux kernel. Overall, there is nothing yet that compares. (BSD maybe, if they can get better sound support). What I want to see is Photon on Linux. The best of both worlds
I figured that since there had been so much controversy over which approach is better, that we’d have to choose one over the other. But from the article, I seem to understand that you can use BOTH? So why are people debating which one is better? Does it matter? What am I missing here?
What is Photon?
gui system that replaced X
Photon is the QNX gui.
Hashem,
The article did not talk about desktop computers. QNX has latencies at around 1 microsecond whereas the article talked about linux with millisecond latencies. They are not in the same league.
Hmm, the topic was tending towards Linux, Windows, and NT (see first few comments) so that’s what I directed my comment towards.
<blockquote>In fact, anything that comes close to the perfect desktop would have to be based on the Linux kernel. Overall, there is nothing yet that compares. (BSD maybe, if they can get better sound support).</blockquote>
For Intel this is possibly true. If you want to include other platforms, though, I think Mac OS X certainly compares. (Perhaps it could be considered BSD.) In fact, having used both Linux and OS X, I would say OS X basically trounces everything else on the desktop from the standpoints of usability and consistency, and I would also go so far as to say that in my opinion it is probably the best desktop OS ever, with an honorable mention to BeOS.
Alex
> The article did not talk about desktop computers. QNX has latencies at around 1 microsecond whereas the article talked about linux with millisecond latencies. They are not in the same league.
Is that QNX hard realtime latency time? I think the value stated in the article are hard realtime latency time for linux.
QNX can do that, RTLinux can do that. The process running with 10 microsecond or less latency is not much of a process by normal OS standards though. You’re not talking about Mozilla, or vim, but more like something that does pointer arithmetic and waggles I/O control lines.
QNX and RTLinux support a world where SOME things (opening the emergency pressure valve) are hard realtime and must happen in 10 us or the boiler will explode, while other things (such as displaying the current pressure to a boiler engineer) can tolerate much higher latency, 10ms or even 500ms because humans don’t think very quickly anyway.
In the RTLinux design the ordinary Linux kernel is used to support these “slow” processes and can be interrupted by the high priority real-time processes.
The ordinary Linux latency stuff is not comparable to RTLinux or QNX because the processes being measured here don’t waggle I/O control lines, they do floating point maths or blit graphics onto a framebuffer. They demand virtual memory, RAID arrays and network access and the added complexity costs latency.
The reason why people bother with Linux and with soft real-time rather than building everything with hard deadlines and proprietary RT operating systems is that there are a lot of applications where missing a scheduling deadline is bad, but it’s not economically bad enough to justify the extra expense of a totally reliable system.
The most obvious example on Linux is audio processing. If my friend Steve uses a Linux audio recording suite for two weeks and during that time Linux causes one under-run, wrecking a 5 minute take, he will be annoyed. However he won’t be annoyed enough to spend $5000 on a proprietary alternative that is guaranteed to eliminate the problem.
OTOH If the same thing happened once a year, obviously Steve would be overjoyed ($5000 to put up with one glitch per year? Who wouldn’t jump at the chance) and if it happened once a day it would quickly get annoying and he would spend the $5000 rather than put his fist through the monitor.
So this is why things like “5 nines” are interesting on Linux, as well as the raw “worst case” latency guarantee.
Many readers of this site know that BeOS was chosen as the foundation for RADAR in part because of good low latency audio performance. It remains to be seen whether the same reputation can be created for Linux audio.