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)
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?
Can this be run on my Pentium4? What is it?
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
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.
Probably not - realtime operating systems are primarily for embedded systems, not desktop systems. Think 'if this task doesn't run in the next NN microseconds then [hundreds of people will die]/[millions of dollars will be lost]/[the software will crash]/[bad things will happen]/[etc]'...
Sorry to say but, you don't really understand the concept of real time.
First of all, an OS being RT has nothing to do with its size. It could be 18 terabytes, or 4 kilobytes and still qualify as real time, as long as it did a few things within certain thresholds.
To be a simplistic about it as possible, the only thing a real time operating system needs to do is to emphatically guarantee that it will respond to interrupts within a pre-determined amount of time. Even this time isn't exactly important, obviously it should be small, but as long as the time constant is known and guaranteed it qualifies as a real time operating system.
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.
Note that several companies/vendors/instutions have provided incarnations of real time linux in the past (and currently). They do this by modifying the kernel source to make sure program ISR's get called within a set threshold. For example FSMLab's RTLinux has a worst case response rate of 12 microseconds.
Real time operating systems are not for everyone. Your system will be slower, but will feel more responsive. Strict server operating systems such as FreeBSD, and the Windows Server class OS's have a much higher ISR response rate. Windows Server is as high as 120 ms. This is done on purpose! They do it to get every bit of performance out of the server they can. Remember, more ISR calls means more interruptions in the CPU pipeline, and more instructions executed per second. On a pentium 4 with its huge pipeline, interrupts are disasterous to execution speed.
Personally I welcome a real time freely available linux kernel. I wouldn't mind sacrificing a little speed for real time operation. If you've ever used a real time operating system, you know what I mean. It's a great experience. But having said that, most people probably won't want that. And that's fine... but having the option is great.
Anyway... before you spout your mouth off and try to sound like you know what you're talking about... learn something first!
THAR IS BOMB ON COMPUTAR
everyone stay calm, if the game drops below 55 frames per second this user will die. Or at least kill alot of people in a fit of rage.
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.
The only one of those that is a requirement for calling linux a genuine realtime OS is the guaranteed scheduling. However, you can already replace the kernel in memory with another kernel, linux has security models in the kernel these days, the boot time is pretty much dependent only on hardware initialization... If linux can get the scheduling to something people are willing to call realtime, that's pretty much the only thing missing.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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.
RTFA. Or (god forbid) the code.
Linux has allowed multiple processes in kernel context at the same time for ages. It's called SMP and/or CONFIG_PREEMPT.
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).
Looks like it.
This function is a non-portable RTLinux extension. gethrtime returns the time in nanoseconds since the system bootup. This time is never reset or adjusted. gethrtime always gives monotonically increasing values. hrtime_t is a 64-bit signed integer.
The actual resolution of gethrtime is hardware-dependent. It is guaranteed to be better than 1 microsecond.
Odd that RT Linux is the first hit in google actually.
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)
No, you don't. In recent time that's been true, but that's generally because the big RTOSs are often used in by vendors who need five nines of availability as well. An air traffic management application not only has scheduling requirements, but it simply cannot crash either, and a microkernel is one design to help pursue that.
A microkernel is not required. In some senses old time sharing systems were RTOSs because they guarenteed whoever paid X amount of money got Y amount of processor, throughput, etc. Those certainly weren't microkernels.
I always worried that my filesystem may get starved by an aggresive real time process in an microkernel based RTOS, but in my experience that's never been an issue. I should look up some research on that one of these days.
A popular RTOS that can be consumed by the masses would be nice.Define masses? For almost all definitions of that term QNX's desktop version (free as in beer) seems to fit the bill. For most others TRON (or is that Tron?) seems to be what you're after. Are there any "masses" that these two OS's don't meet?
It would allowing upgrading the OS without rebooting, guaranteed processor time, nearly instant booting, better security, better reliabilityI think you're talking about a microkernel there, except for the guaranteed proc time. Everything else is one of the (debateable) advantages of the microkernel design.
All the patches appear to do is attempt to get linux to pre-emtively multitask correctly.Actually, it's talking about kernel preemption, which isn't exactly pre-emptive multitasking in the usual sense of the term. When that audio demuxers says "give me the processor!" in an RTOS, then it gets the processor, even if it has to preempt the kernel.
At heart RT is a schduling thing, mainly the processor scheduler. As the RT concept has matured, there has been a desire from ISV to see RT style scheduling of disk accesses, of bandwidth allocation, yadda yadda. These aren't needed to be a RTOS strictly speaking, but they are needed to be competitive. There have existed patches to make Linux a true, hard, RT kernel for quite a while, or to have "soft" RT as well. So, Linux being (at least, being capable of being) a RTOS is in some senses old news.
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.
Are there any benefits for the senior noob who can patch and compile the kernel with the RT features.
No. Real time functionality is not just "better latency". Real time stuff is generally significantly less efficient than traditional schedulers. It's useful for specialized work -- this is not "better desktop" or "better server" for anything approaching the typical Linux end user.
If you're doing control work with Linux, then you might be interested.
May we never see th
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.
Your system will be slower, but will feel more responsive.
You do not need a real time system to "feel more responsive". In most systems, kernel locks simly do not tie things up for anything approaching human-perceptable times.
This stuff is important not for the server or the desktop, but things like control systems.
May we never see th
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)
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.
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.
"They do this by modifying the kernel source to make sure program ISR's get called within a set threshold. For example FSMLab's RTLinux has a worst case response rate of 12 microseconds."
Although you described real-time issues correctly in most of your post this paragraph implies something that is not true of real-time. Real-time is not about being fast, it's about being consistent.
In the toughest real-time situation, the important thing would not be that the response rate is 12 microseconds vs. 12 msec, but that it is exactly 12 microseconds or 12 msec within the resolution of the system. (Obviously the system speed has to be fast enough to meet minimum timing requirements, but that's a speed issue, not a real-time one.)
The easy test to determine if a particular system has hard real-time requirements is to ask yourself if speeding up the system will solve all the problems. If it does, it's simply a performance issue, if not, it's a real-time issue.