This study compares the real-time capabilities of various Linux kernels. It was part of a project to upgrade the control software in water-wave generators at research institutions around the world. The results of the study were used by Akamina for the selection of a new RTOS for the control system upgrade of Canada’s largest hydraulics and coastal engineering laboratory, the National Research Council Canadian Hydraulics Centre in Ottawa.
A comparison of Linux alternatives for hard real-time
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
It’s an interesting test; although it would be great to see a BSD flavor in between.
With all of its new scheduling code I thought for sure the 2.6 kernel would come out on top.
Welcome to the world of fanboys.
http://www.penny-arcade.com/view.php3?date=2004-11-03
This is so stupid I don’t know where to begin.
Ah, much like your post. Ironic isn’t it?
Please, int argc, core dump yourself, and keep the s… out of this thread; taking a look at your post, you have never ever seen a Real Time OS in action. Please, don’t act like a dumb, watch, and learn.
Instead of pointing out the naivity of the original poster in such a way as to portray them as an idiot, try explaining why they are wrong. It would stop OSNews from becoming the /. that it has become as of late.
http://www.fsmlabs.com/products/rtcorebsd/
Notice how much better it is then v2.4? That is due to the improvements to the schedular. A 10x improvement in worst case numbers is nothing to sneeze at. However, RTOSes generally get between 5-50us worst case numbers on this kind of hardware. So the standard kernel still needs another 10x boost to get into the RTOS league.
Fact is, you probably don’t want it to get to that point. At 500us worst case times the linux kernel is now able to ensure that stuff like audio will never under-run and that there won’t be any user perceptable jitter. All without sacraficing too much I/O thruput. Nothing comes for free, and there are always going to be trade-offs. I would hate to see the standard Linux kernel trade off anything that impact server/workstation performance for latency numbers that won’t effect most people.
At 500us worst case times the linux kernel is now able to ensure that stuff like audio will never under-run and that there won’t be any user perceptable jitter.
Which would be fine if the driver didn’t produce so much static along with normal sound (NForce2 onboard sound).
***
Would be interesting to see a comparison against QNX which, afaik, is real-time designed from the ground up as opposed to being re-tasked.
Would be interesting to see a comparison against QNX which, afaik, is real-time designed from the ground up as opposed to being re-tasked.
Yeah, I know a few things about QNX.
There are numbers you can get from http://www.qnx.com on myQNX. I think you have to sign something (NDA-ish) to get access. You can also look for the white paper comparing QNX to VxWorks AE, WinCE and stock Linux v2.4.
that’s not true. vanilla kernel 2.6, with or without preemption still has problems with real time audio (i’m talking about audio/music production with jack, ardour, plugins, etc). low-latency patches are STILL required and will continue to be for the forseeable future it seems.
Well, the stock v2.6 kernel has Andrew’s pre-empt patches integrated. From what I can tell, Ingo’s patches are no longer kept up-to-date with the 2.6 kernel series.