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."
Does this mean i won't have to adjust my clock any more? ;)
GAAH! MY PRINTER IS ON FIRE!!! PUT IT OUT! PUT IT OUT!
Combined with the ability to remove portions of the linux kernel that you aren't use, this is one more step toward world domination by Linux. Currently the same linux kernel can be used for everything from non-realtime embedded projects (typically implying a certain amount of horsepower, but these days, not an MMU!) up to NUMA-based multiprocessor workhorses. With Linux running (or capable of running) on many of the most powerful systems on the planet it is easy to forget about the other end of the spectrum which is no less important. This is a step necessary to get Linux into applications like engine management systems, besides the applications (like GPS) cited in the linked article.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Your attempt was pre-empted by a higher priority post. I guess the RT patches work.
There are no karma whores, only moderation johns
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.
Do you all think these will be merged and ready before 2.6.9 is released?
op. system that boots in a second (would be quite useful for a home user) :)
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?
RT LINUX will be used for what?
RTAI has provided hard real time support for the 2.6 kernel since may!
Does this finally mean Linux will have something like Solaris' gethrtime()?
Fantastic news for the future of Linux's responsiveness. I can't wait to see things like X being improved significantly in terms of responsiveness because of this. It won't only benefit embedded systems.
Can this be run on my Pentium4? What is it?
I will stand using a true RTOS link=www.rtmes.com .
It may not be a troll, but it is off-topic.
Continuing the same off-topic-topic, I have a question: Are there figures on the percentage of PCs used to play games? I get the feeling most of the companies pushing linux are pushing it for business use, which suggests that the business market is larger...
Phil
I guess today is a passable day to die.
Windows.
"I use a Mac because I'm just better than you are."
Real time means that processes can have an absolute time where they have to be finished. Mainly, because that means they produce output, and that output is needed THEN, not 'later'. For example, an automatic flight manager in an airplane needs his data by time to adjust in time, and needs to run at least every once and then to check if everything goes well. If the 'system' has a lot of work to do and gives the automatic-pilot-process to little time, the plane WILL hit that mountain you're heading at. RealTimeOS's account for that and make sure certain processes are excecuted more often than others since they have an higher priority.
For the more techies: this is not like priorities in non-rt-kernels where an higher priority results in more timeslices in the round robin algorithm, it means that it isn't interrupted until it reaches a certain 'done'-state. And if a process depends on an other process (radar automatic pilot relationship-like) that process will be run prior to the automatic pilot process, to assure the automatic pilot gets new data, and no old data or old/new mixed data.
It is a nice addition to the linux kernel. Not very usefull for the every-day-workstation, but very usefull for the portability of it. A couple of whole new markets suddenly now have the possibility of choosing for linux. (unfortunately, those markets don't just 'switch', same reason as nasa using 8086's in their spaceshuttles)
- waccolodian.blogspot.com
"A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
[Reuters] At 7:29PM on Saturday, October 8th, geneticists at the University of Southern California released evidence that shows conclusively that the world had officially created a better idiot, as per the idiom, codenamed "Project CodeDark". This news comes just hours after the second nationally-broadcast presidential debate, leading some to draw the obvious connection between the two. Film at 11.
I'm not saying that we'd throw away the kernel, but rather that if it updates itself there may be bugs in the patch itself.
But I probably misread parts of it, too. Sorry for any confusion.
- Code Dark
When my computer boots, it's mostly just the harddrive grinding. Unless the kernel can make my harddrive spin faster, I doubt you'll see much change in boot times.
How does this patch set compare to Ingo's voluntary preempt patch set? Is one better than the other? Could they be combined in a useful way?
And of course, Montavista stole all this code from SCO since there is no other way Linux could have gotten real time capabilities that were already present in System V Unix. SCO to sue Montavista, film at eleven.
Linux is a monolithic kernel. To be an rtos you usually start with a microkernel: Qnx, VxWorks, Hurd. In order to turn linux into an rtos they would have to rework it from the ground up. In addition they would have to completely break backward compatability. A popular RTOS that can be consumed by the masses would be nice. It would allowing upgrading the OS without rebooting, guaranteed processor time, nearly instant booting, better security, better reliability, and tons more. All the patches appear to do is attempt to get linux to pre-emtively multitask correctly. This by no means will make linux a real time os.
:(){
Since version 7 the audio and video has no synchronizing problems that I've seen, and that is on various boxes. It was a big problem with v6 though, maybe you want to try and upgrade? It has been available for months now...
;-)
Another possible reason would be if you are using arts or esd. Sound daemons can mess up sync pretty badly, never ever got it to work properly with mplayer or flash as examples, so now I'm using dmix instead. Which, in turn, has other issues, the one that annoys me being that I have to stop playing all other sound sources before starting firefox if I want to hear sound in flash movies. And no, piping firefox via various translating programs alsa/arts/oss you name it, does not work. Usually that just makes everything crash.
Spine World
Good question. Answer: it doesn't. Unless you're RedHat, Novell, IBM, or one of the other organisations with a commercial interest in it.
The problem, as I see it, is that we need these guys on board because they plough a lot of resources into linux and that ultimately benefits us. Thus we need to pretend that the market-share of linux matters, while continuing to realise that it's a worthless metric.
Phil
I guess today is a passable day to die.
This incorporates some aspects of Ingo's VP patches that are prerequisites for any kind of RT support the kernel. These include offloading all softirqs to ksoftirqd (normally softirqs run immediately unless the load gets too high in which case they hand off to koftirqd) and IRQ threading, which created a separate thread for each irq and offloads hardirqs (aka the "top half" of an interrupt handler) to that thread. If you stop here the latency is about as good as OSX.
This is where the two approaches diverge. The VP approach uses normal kernel preemption, with the addition of scheduling points with optional lock break inside spinlocked code. But you still cannot preempt code that is holding a spinlock. This becomes the lower bound on latency.
MontaVista goes even further, replacing spinlocks with priority inheriting mutexes, so you now can preempt code that would not be preemptible with VP.
In practice VP gives better latency right now by about half. But as another poster pointed out this is probably due to debugging overhead and probably a few bugs, the VP approach has reached the limit while this is capable of improving worst case response times by a few more orders of magnitude. This is a great development.
How did he get 0, Troll and not +4, Funny?
/., AOLers are gonna be confused enough anyway.
Okay it might mislead newbs, but this is
Phil
I guess today is a passable day to die.
Thank you very much for your informative explanation.
Does OSX have this latency because of its semi-microkernel nature? Otherwise, what is it about OSX that makes it have relatively low latency?
Given this new development, do you think Ingo will change tactics and adopt the new approach into what he is doing? Or are there any reasons why he shouldn't?
Excellent commentary. Unfortunately, blocked by /. indentation scheme...
There's no time to stop for gas, we're already late.
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).
I have used Linux with the RTHAL patches for data acquisition at high data rates synchronized by an external clock. A specialized application, yes, but useful nevertheless. Having this functionality completely rolled into the kernel will be nice.
There are two types of real-time, soft and hard. This is how you distinguish the two:
Hard real-time says "Do this within the next ## seconds or you might as well not bother as we'll all be dead". Soft real-time says "Do this within the next ## milliseconds if you can, otherwise the sound on the DVD playback might skip".
The parent is talking about hard real-time scheduling, which is what these patches help with. Hard real-time has sharp deadlines, enormous penalties for missing a deadline, and (relatively) long periods between deadlines. Of course, there are short-deadline hard real-time systems, like ABS controllers in cars; however these tasks will usually be handled by dedicated hardware.
Soft real-time is a more interesting topic for desktop Linux, because you aren't usually in a situation where your desktop machine can kill you by inaction. Soft real-time has fuzzy deadlines, small or no penalties for missing deadlines, and (relatively) short periods between deadlines. DVD playback is a good example: if a frame is delayed by a small amount or even skipped entirely the viewer is unlikely to notice provided it doesn't happen too often. Same for games.
Phil
I guess today is a passable day to die.
Timesys were next. I used Timesys at the last place I worked - it's good, but it's also inconvenient. They only seem to provide pre-patched kernels, and there's quite a bit of support stuff that's not GPL.
RT-Linux uses a similar technique to RTAI, to achieve real-time. There is a questionable software patent on the precise technique they use, which is (in theory) to prevent non-FOSS companies from obstructing real-time Linux work. It's unclear as to whether the patent could be used by hostile companies as "proof" of the IP "dangers" of Linux and FOSS in general, but there's always that risk. The problem with minefields is that they don't care who steps in them.
For those using older kernels, and only requiring "soft" real-time, then the real-time scheduler patch on Sourceforge might be sufficient.
That brings me to my other point. "Real-time" is a gradation, not a binary state. True "hard" real-time is extremely difficult to achieve, as it must be impossible to block any kernel thread or any interrupt. Your clock device also needs to be stable. The more exacting your requirements, the less you can afford to have even the smallest amount of drift.
The 2.6 preempt work, from what I understand, covers the bulk of the kernel but is not absolute. In other words, some things are simply going to block, like it or not, and that in turn means that you cannot absolutely guarantee a process a controlled time-slice.
For most real-time stuff (eg: basic multimedia stuff, etc) you don't need anything like as fancy as "hard" real-time. You simply aren't going to notice if a DVD is skewed by a couple of milliseconds - or even a couple of seconds - over a playing time of maybe 1-3 hours.
For that kind of stuff, "soft" real-time is certainly adequate. It smoothes things out to the level any person is likely to care about, but doesn't go much further.
Now, if you're in charge of a nuclear reactor or are designing the fly-by-wire systems for a Mach 10 aircraft, then any blocking is probably going to be unacceptable. (On the other hand, if you're in charge of a system like that, what are you doing reading Slashdot? Hey, what's that blinking red light, over your left shoulder? Uh-oh...)
There are patches for Linux, which give it nanosecond granularity. I don't know of any real-time patches which can make use of this level of precision, but there may well be projects where you really do require accuracy at that level. (Again, though, DVD playing is probably not one of them.)
It's great to see RT-Linux enter the 2.6 series, but it really isn't the first. That should not detract from users, though, because (frankly) who cares? If you're an admin or a user, you're concerned with whether it works, and the RT-Linux folks certainly know what they're doing.
Linux is progressing nicely in many of the top areas of high-end computing. Clustering, real-time, pre-empt, journalling filesystems, high availability, distributed shared memory, LVM, gigabit and ten gigabit ethernet, network QoS, nanosecond precision, etc. On the other hand, M:N threads seem to be dead, OpenMP is restricted to commercial software for Linux and many of those areas which are, in some way, being developed are disjoint and don't always work well together.
In other words, there is (as always) room for improvement, but what there is is certainly extremely impressive. Linux is rapidly developing a solid reputation in the high-end markets, and deservedly so. I look forward to seeing what happens next.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Dude, Linux scans your brain!
There are indeed legal issues, but they are
solvable. The FAA now lets Linux do everything
except operate the controls. The FDA is OK with
various X-ray things made by Siemens Medical.
I suspect your Windows RT provider is in violation
of the RT Linux patent. What will you do if they
get sued by TimeSys and discontinue the product?
You'd be much safer using Linux. At least then,
your code would stay portable. You wouldn't need
to worry about losing your ability to ship product
so much -- worst case, you choose another one of
the many UNIX-like systems. For Linux alone you
can choose: TimeSys RT Linux, RTAI, Montevista's
Hard Hat Linux, Concurrent's Red Hawk Linux, and
of course roll-your-own Linux.
Does OSX have this latency because of its semi-microkernel nature? Otherwise, what is it about OSX that makes it have relatively low latency?
From reading the I/O Kit docs (the driver writers guide for OSX, google for it) it looks like OSX does it the same way as Linux with Ingo's patches, they have a preemptible kernel and a realtime scheduling class for multimedia apps, and IRQs appear to be threaded, though the exact mechanism is unclear. The Mach ancestry helps in other areas, Mach ports on OSX are allegedly are a faster IPC mechanism than even Linux FIFOs.
Seems your 'r' is also pre-empted and echo-ing as a side effect.
Lots of background noise but nothing specific.
So if someone can sumarize:
Are there any benefits for the senior noob who can patch and compile the kernel with the RT features.
What is the latest verdict with preemption (and how would the RT patch play along with it)? To enable or disable... it was never settled.
http://kerneltrap.org/node/view/3966
http://kerneltrap.org/node/view/2702
Windows 2015 that is!
So a blue-screen is worse than a panic now?
There are operating systems other than Windows, Linux, *BSD, Unix, MacOS, OS X, OS/390 and z/OS which are far better suited to running the software which controls my car than any of the aforementioned.
This is because an OS designed from the ground up for real-time, safety-critical tasks will always beat an OS designed for running word processors, compilers, business applications, games, or multimedia editing software when it comes to controlling my car.
Phil
I guess today is a passable day to die.
open4free ©
open4free ©
What does embedded mean anymore? It's hard to define. An MCU in a microwave is defintly embedded but what about the processor in a new high end digial oscilliscope? IMHO test and measurement would usually be considered embedded, it is deffinitly real-time. If a scope doesn't acuratly record/display the data it is monitoring acuratly as a function of time then it is useless.
...though I don't miss the Bay Area at all.
[Abridged version: I took a two-week vacation to Austin TX, and never got around to going back. The "oh, hey, I'm a remote employee now" bit was, entirely understandably, not well-received]
MontaVista's engineering department is absolutely the best place I've ever had the privilege of working. Really, really good people; clueful management (though I hear they've lost their VP of Engineering since I left -- that's a shame; I still haven't had a better manager); lots of opportunities to learn and do new things and come up with (and follow through on) R&D projects.
Not that my new job sucks, by any means -- I'm now the (pretty much only) systems-level generalist at a Java shop making a next-generation EMR system -- but it's not quite the same as spending ones' days hacking and debugging C (and Python, for some internal tools) surrounded by folks doing the same.
I wish they'd use a different name for this. The product "RTLinux" already exists, and it's not related at all to what Montevista is doing. It's the microkernel based "run Linux as a thread" approach taken by Victor Yodaiken at FSMLabs. According to this article it was first released in 1995, predating the existence RTAI and Montavista by many years.
Perhaps Linus is in talks with Valve to distribute kernel patches via Steam! Har har har ...
MontaVista is a good vendor which primary occupation is developing Linux distros with RealTime kernels for various embedded platforms. And by the way, they are RTOS developers in past.
Didn't 2.4 kernels already have these patches? or is it just a gentoo thing? :-)
I've been using the stock gentoo 2.4.26-r9 kernels with realtime scheduling option selected for a bit now, getting 5ms or less latencies without problems with my software synthesizers (5ms is not technically realtime, but it's the lowest setting there is in (my current) qSynth (uses fluidSynth & Jack), and I can actually mute the piano now and play through the computer without delays, last time I hooked it up it was 450ms on a winshame box)
I've got nowhere near 5ms on 2.6's yet. Which is a shame because the hardware support in general is getting damn good.
With this scheduling hopefully becoming standard, I think it's time I write some guitar effects software...
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.
Wouldn't multi-processor systems be ideal for a real time operating system? One (or more) for real time processes and another for OS processes.
-- Checking emails and kicking cheats `till the day I die.
It'd be great to see realtime capabilities in the vanilla kernel - though in the meantime for a low latency Linux multimedia system I recommend the Planet CCRMA low latency kernel based on Fedora/Red Hat - this has a huge repository of compatible software, much of which is of very high quality. See Ardour (Digital Audio Workstation) for instance. Planet CCRMA uses the Advanced Linux Sound Architecture (ALSA) drivers (which have OSS emulation).
I don't think the RT Linux patches for the 2.4 series were EVER merged.
retrorocket.o not found, launch anyway?
LynxOS is not Linux. It can run linux programs natively, which is pretty impressive, but it is not a certified real-time safety-critical variant of Linux.
Phil
I guess today is a passable day to die.
On the other hand, there are a number of differences in what they install. Get both, and dual-boot.
Why?
The topic is $COMPANY_A making a contribution to the Linux Kernel. I'm reminiscing a bit about having worked for $COMPANY_A actually doing all that great stuff. (Well, not quite -- I was mostly userland, though there was a bit of kernelspace work as well).
I think it's reasonably topical.
but it seems to me that, if I'm understanding what this does correctly, it to some extent increases the vulnerability of the system. What happen if a virus, say, preempts the entire rest of the system and takes up all the execution time?
Because DeMuDi is stuck on 2.4, certain pleasantries of the desktop environments (like udev) are missing. On the other hand, the 2.6 alsa integration fails to set up my sound cards properly. More specifically, it doesn't allow me to set them up the way I want, although it is fairly likely that I just haven't figured it out.
One thing I don't understand about DeMuDi and Planet CCRMA is the default of Gnome. I'm personally pretty ambivalent about DE choice, but it seems to me that it would be a good idea to use the environment most fitting for the tools offered in the distro. All of the nice GUI sequencer/notation programs are qt/kde programs.
best. typo. ever.