Slashdot Mirror
RT Linux Patches
sally bitter writes "Linux 2.6 kernel Real-Time? It is going to happen soon. Montavista developers submitted patches today to LKML to begin testing all the low latency task preempt and interrupt stuffs they're introducing."
← Back to Stories (view on slashdot.org)
Will this affect desktop usage for the better?
Would the benefits of this be just for embedded devices, or would more traditional uses also benefit from these changes?
"I use a Mac because I'm just better than you are."
Where I work we did a project using Timesys Linux which implements true real-time support and has some really cool scheduler options. For example, with Timesys, you can, for example, guarantee that a task will get a minimum of 15.7ms execution time every 31ms. It even allows you to set priorities for interrupts, such that an interrupt can be scheduled at a lower priority than a user thread. And finally, they added support for priority inheritance to avoid the problem of priority inversion, which occurs when a low priority thread has acquired a semaphore and a high priority thread blocks on it.
Not only can you reserve CPU bandwidth, but also network bandwidth. Of course it also has all the other standard features one would expect of a real-time OS.
Sadly, Timesys has not applied their patches yet to the 2.6 kernel at this time.
-Aaron
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
Will Flash animation files finally have audio and video synchronized? Of course I'm actually starting to believe they are all probably out of synch for stylistic reasons... Anyone else get that way too?
If you're stripping out the parts of the kernel that you're not using and you're only running a single process or doing everything through drivers/modules, there's very little to go wrong. Linux's broad hardware support using the same source tree must be quite appealing to any developer, since their project can be "trivially" moved to basically any other processor that has enough power if they decide they want to switch. Your most highly-optimized code will probably always be written in assembler or in very very simple C that takes the hardware into account and uses few functions not defined in the program itself, focusing mostly on direct hardware access, but this will be a minimum of the project in general.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Can this be run on my Pentium4? What is it?
It completely depends on what they mean by "real-time', since it depends on a whole bunch of things.
Personally, I'd be satisfied if they (or someone) semaphored everything at a low enough granularity to allow multiple processes in kernel context at the same time.
Modcomp did that back in the late 80s or early 90s, and their real-time UNIX kicked ass (Real/ix). Too bad that company's not doing much with it now.
Understand this:
These and other real-time patches do not reduce the average time required to do a system-call on your system (they probably increase it slightly).
Real-time priority only has an absolute meaning if you have a single-process system.
What real-time means is that a process or thread with a real-time scheduler (SCHED_RR or SCHED_FIFO) and higher-priority than any other process/thread in the system will complete its work in the shortest possible time. You can use the POSIX real-time calls to eliminate multiprocessing: set the scheduler to SCHED_FIFO and the priority to max on every process in the system and bingo, batch processing.
If you want your gnome or kde desktop to respond more rapidly, you probably need to make several processes real-time. The more real-time processes you have, the less real-time means -- if you set everything to realtime priority you're back to where you are now. Judicious use of SCHED_RR and balancing priorities might net you some improvement, but probably not enough to notice.
There are possibly some benefits to making multimedia apps such as xine run real-time, but unless you have playback problems now you won't notice the difference.
Phil
I guess today is a passable day to die.
Actually, there are RTOS UNIXes running desktops. From three years ago, I'm used to run the Posix Desktop over LynxOS 3.0.1 (nowdays on 4.0.0), running gvim, emacs, xmame, and so on. The only missing thing was USB and sound card support (still not supported on v. 4.0.0). There is also XFree support, at least for LynxOS, but may be too for QNX et al.
There are, of course, disavantatges, you can not archieve the same disk throughput on current RTOS compared to Linux or Windows. From my experience, both ethernet and IDE throughput it's far from being optimal on a RTOS (think about 60-80%). But that it is commonsense, if you want kick ass response times, you'll lose a bit of throughput and viceversa.
There is other important points, usually, on RTOS the disk-cache has a fixed size, processes are limited to a relatively low number (usually 100 to 500), and many other limitations.
The resume it's quite easy, if you want to have a RTOS you should be sure you have, at least:
1) Preemptible kernel
2) Inverted priority detection (to avoid thread stalls; this point it is not 100% solved on most commercial RTOS)
3) Acotated resources
3.1) Deterministic disk cache (usually fixed length on most -current- implementations)
3.2) Limited process handling (that point may will be specially good for Linux and the O(1) scheduler, as other RTOS have poorest scheduling scheemes; could be amazing having thousands of threads without penalization... beating commercial RTOSes (!))
(This thread it's amazing, but I'm tired; 2:30 am here, I have to leave without adding a more complete comment, sorry).
There's one very big field of use in using linux as audio platform. Previously Ingo Molnar's Voluntary Preemption patches and now also this RT linux stuff (which seems to partly build on top of the VP stuff) enable linux users to run audio applications with latencies down to the sub 1ms range.
Threaded and nonthreaded IRQ handlers are available with Ingo's VP patches today. Average kernel latencies around 10 - 80us are possible today, too. No garantees made about the worst case though with VP, but in day to day use i seldom see a non preemptible critical section longer than 200-300us.
And with the help of the realtime lsm which enables (certain) non root users to use the SCHED_FIFO scheduler class (and to mlock application memories), linux beats the sh*t out of ms windows and is easily on par with mac os x wrt to achievable latencies.
Jackd and other linux audio apps are still a bit rough and sometimes a bit buggy, but stuff is really starting to stabilize and get really really useful.
Man, i waited 10 years for linux to become my ultimate audio workstation OS and now it's finally happening. RT linux will only make it even better!
P.S.:
Check out the apps section on the JACK pages to see what's available today:
http://jackit.sf.net/apps
Most of the time I don't have too much trouble with it, but it doesn't synch up. Having seen a few of these files on someone else's computer, it's made it all the more obvious to me.
Someone above you mentioned that it was Macromedia's fault, and that may be. With each release, the player seems to get a little better (at least they are watchable on sites like Newgrounds and Atom Films now), but the audio and video still don't line up quite right.
Of course Judging from the mod slap I just got, I get the impression that RT Linux wouldn't be the right tool to solve audio synch problems in such cases...
I'm not sure I would call VxWorks a microkernel. In VxWorks, everything is in the same address space. There's basically no memory protection (unless you count the bastardized VxWorks AE). Think of VxWorks as the ultimate monolithic environment, where everything goes into the kernel.
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
Linux has been evaluated and certified for safety critical applications. LynuxWorks and Rockwell Collins worked together to certify a specific Linux kernel and distribution to
DO-178B Level A certification.
DO-178B is the standard for software on commerical aircraft. It's difficult and expensive to do, but it's required by the FAA. Level A is the highest level of certication. Level A certification is required for critcal components like the displays, fight controls and the auto-pilot.
There really aren't any software certification standards that are more rigorous than DO-178B, and Linux already has been certified.
Could you give some quantifiable reasons why you think Tenasys is in violation of the RT Linux patent?
"Do or do not. There is no try." -- Master Yoda (Half man, half muppet)
Real time linux is NOT "a true RTOS running linux as its lowest priority thread." That doesn't even make sense! You've obviously never done any kernel programming, or bothered to do any basic knowledge gathering on operating system design at all.
Perhaps you might like to tell certain large Japanese A/V companies about that, since they do EXACTLY that (run Linux as a task under a uITRON RTOS). I think you maybe need to learn something, too.
Jon.
The NTP protocol is over-engineered for what is fundamentally a relatively simple problem. The NTP implementations 4.2.x have at least two -- probably many more -- currently unreported heap and buffer overflows which should be remotely exploitable.