First page Back Continue Last page Summary Graphics

Other efforts

Notes:

Full quote:

_if_ there are truly hard guarantee requirements, RTLinux is the way to go.
The number of problems that really need RT-linux is practically zero for normal uses. This is, btw, why I've never applied the RTLinux patches to the standard kernel tree. My personal opinion is that the RTLinux patches should _not_ be available by default, so that only people who really need the functionality start using it.
Having non-hard-RT users start using the RTLinux functionality would be a disaster, in my opinion. The programming-interfaces are much more cumbersome, and the ways of making the system lock up hard are many and varied.
If you do a computer-controlled radiation-dose machine for treating patients, and the latency guarantees have to be in the sub-100ms range, THEN you should use RTLinux.

If you're doing just audio that needs approximately 1% fo the CPU resources, and you have to use hard-realtime, the system needs work. Using RTLinux is a way of saying "oh, we can't fix this properly".

NOTE: I'm fully aware of the fact that Linux needs improvment in this area. I've tried to explain that my beef with the low-latency patches has never been that I don't believe it is a worthy goal. It's just that I also firmly believe that there are right ways of doing this. Without ugly patches that add random stuff to random places.
http://kt.linuxcare.com/kernel-traffic/kt20000717_76.epl