RT Linux Patches 170
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."
Desktop Usage? (Score:1, Interesting)
Re:Desktop Usage? (Score:3, Informative)
Re:Desktop Usage? (Score:3, Funny)
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.
Re:Desktop Usage? Why not?! (Score:4, Interesting)
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).
Re:Desktop Usage? (Score:2)
From the second paragraph of the article...
I don't know how long it will take until it's delivered in the default kernel and some applications actually use it, but it will sure be a good thing.
Re:Desktop Usage? (Score:2)
For desktop use you're unlikely to notice much difference. Improved disk cacheing/swap management is a much more
Benefits? (Score:2, Interesting)
Re:Benefits? (Score:5, Informative)
Embedded or not embedded? (Score:2)
Re:Embedded or not embedded? (Score:2)
Re:Benefits? (Score:2)
I agree with the parent, having sold my WRS stock long ago. Years ago I remember having an argument with a manager at WRS about embedded linux. He laughed it off, swearing it wasn't going anywhere. Now they've seen the light and are trying to support em
Re:Benefits? (Score:5, Interesting)
Re:Benefits? (Score:5, Informative)
Re:Benefits? (Score:5, Interesting)
Re:Benefits? (Score:1)
Medical and aviation already using Linux (Score:2)
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 -
Re:Medical and aviation already using Linux (Score:2, Interesting)
Re:Medical and aviation already using Linux (Score:2)
the patent. TimeSys does other stuff. Sorry.
The patent covers running a regular OS as
the low-priority task of an RT OS. Either
your Windows RT provider does that (some do)
and you're in violation, or your Windows RT
provider does do that and doesn't work right.
Pigs will fly, given sufficient thrust, and
the RT Linux patent is the thruster you need.
Windows alone is not even close to being an RT OS.
The whole point of the RT Linux patent was to
block Windows from using th
Re:Medical and aviation already using Linux (Score:2)
The "driver" is the RT kernel. It's a Windows
driver, but not a normal one. It must load as
a driver to get the required hardware access.
(just like VmWare pretends to be a driver)
This "driver", really an RT kernel, is trusted
to run tasks with proper priority. Windows itself
gets the lowest priority.
I think you'd best plan for what to do when a
lawsuit comes along. Note that, since this is
a patent, a mere user (you) would be in trouble.
If FSM Labs wanted to be jerks, they'd su
Re:Medical and aviation already using Linux (Score:2)
FSMLabs, Inc [fsmlabs.com] owns the RT Linux patent [gnu.org]. Timesys has unrelated technology based on patching the stock kernel, similar to what Montevista does but not as good.
Re:Benefits? (Score:2)
Re:Benefits? (Score:4, Informative)
I work with quite a few (11) FAA level D flight simulators running linux with realtime patches. Realtime ability is a must in flight sims because glitches and slowdowns are not tolerated. A realtime or at least psuedo-realtime OS allows us to guarantee that the simulation processes will always have priority over non-essential tasks (even OS tasks that aren't necessary to the simulation).
Re:Benefits? (Score:5, Interesting)
I've flown a lot of sims over the years (annual recurrency for multiple types adds up to a lot of simulator time). I'm really curious now who's building them on linux, wondering if I've actually flown one of those.
Re:Benefits? (Score:2)
FAA is somewhat more lax than Transport Canada in this regard. I haven't check recently, but I was looking at specs about 9 months ago as defined in the CARs. One of the requirements that really stuck in my mind, was that they require daily logs (hard copy) of the latency checks. there were a few other requirements in there that made is start to rethink the whole concept. We were compa
Real time? (Score:5, Funny)
Comment removed (Score:5, Informative)
Re:Real time? (Score:2)
Good news, folks (Score:4, Informative)
Re:Good news, folks (Score:5, Funny)
The first pile-up after they're introduced and slashdot'll be covered in "So that's what a beowulf cluster of Linux EMUs looks like".
Re:Good news, folks (Score:3, Interesting)
Re:Good news, folks (Score:2, Insightful)
Re:Good news, folks (Score:2)
Re:Good news, folks (Score:3, Insightful)
The linux (kernel.org) codebase is not really stable enough to meet the needs of embedded systems. If someone wants to build an
Re:Good news, folks (Score:2)
Each new kernel
Re:Good news, folks (Score:2, Insightful)
I hope this happens, as a lot of the work they would need to do to get certified would benefit desktop linux, particularly in the realm of hardcore POSIX conformance.
Phil
Re:Good news, folks (Score:2, Insightful)
There are embedded OSs for which every line of code has been checked and audited. I think that's a good thing where lives are at stake. For Linux to meet those requirements would require a massive slow-down to the development effor
Re:Good news, folks (Score:3, Interesting)
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'
Re:Good news, folks (Score:2, Informative)
Re:Good news, folks (Score:3, Informative)
Here [lynuxworks.com] is the link I indended to include originally.
Here [lynuxworks.com] is a recent press release about a Rockwell Collins Program that is going to use it.
Here [dedicated-systems.com] is a press release from when it was first announced.
Re:Good news, folks (Score:2)
Seriously, I can't think of any OS I'd trust more than linux for the really critical stuff.
Re:Good news, folks (Score:2)
What is this constant facination with the desktop? People switch to Linux when they get sick of Windows. Developers sometimes contribute to it. Linux gets better. What does it matter what % of the market linux holds?
And most people who buy and use computers are not gamers (suprise!), although games do have a driving effect on linux development.
Mod parent up pls (Score:1)
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
Re:Good news, folks (Score:2)
I agree that Linux cannot dominate without more attention being paid to gaming. However, I go a step further than you do, because I think it can't do it while you need special software to actually play the games. The games are going to have to be Linux native before it can really happen. I figure the way to get there is to use Linux on gaming platforms. Someone should really do a game console that runs Linux, uses OpenGL and SDL to do its output, and which has hardcore DRM, as much as I hate to say it, bec
Re:Good news, folks (Score:4, Funny)
Piracy never really affected the Sega CD, because no one actually bought the thing. }:)
-Z
I wonder if it's true real-time (Score:5, Interesting)
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
Re:I wonder if it's true real-time (Score:3, Informative)
-Aaron
Re:I wonder if it's true real-time (Score:2)
What if three tasks told the system "I need a minimum of 15.7ms execution time every 31ms."
Would the third one get an error? (Well, the second should actually because after the first takes his chunk, there is only 15.3ms every 31ms.)
Just wondering how robust it is...
Re:I wonder if it's true real-time (Score:2)
Re:I wonder if it's true real-time (Score:2)
Re:I wonder if it's true real-time (Score:2)
Re:I wonder if it's true real-time (Score:4, Informative)
Not to be rude - but I'm pretty sure you're mistaken. I've been a developer at TimeSys for several years, and I've never heard anything of the sort mentioned by anyone here. Searching LKML via Google, I can't find anything [google.com] that accuses TimeSys of violating the GPL, or anything remotetly simiilar to that.
If you have something specific you want to point out, please do so.
Re:I wonder if it's true real-time (Score:2, Informative)
This is BS. The Timesys people have posted lots of quality GPL'ed code to LKML. They have never been accused of violating the GPL by anyone credible.
Troll.
When will these be merged? (Score:2, Insightful)
Re:When will these be merged? (Score:2, Insightful)
his rants over the code.
My bets are by 2.6.18, any takers ?
Re:When will these be merged? (Score:2)
According to the announcement the patches cause failures during high load and low memory conditions. There are other known problems.
These patches will require a lot of vetting before they're merged imnsho. They'll probably spend a few months in -mm in the very least.
Cheers
Stor
Probably not (Score:2)
Does RT == Better Synch? (Score:1, Interesting)
Re:Does RT == Better Synch? (Score:1, Informative)
Cleary it's sloppy programming on Macromedia's part.
Not a problem anymore (Score:2)
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 s
gethrtime() ? (Score:1)
Re:gethrtime() ? (Score:2, Informative)
Looks like it. [rtlinux.org]
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.
What is Real Time exactly? (Score:3, Interesting)
Re:What is Real Time exactly? (Score:5, Informative)
This is generally split into hard real time and soft real time.
In a hard real time system, if a task misses a deadline, the task has failed. You might as well not do it. This sort of thing is important for, say, control systems that determine what thrusters to fire when on the Space Shuttle.
In a soft real time system, you have some penality if a task isn't finished by a certain time.
One kind of real-time functionality that a system might provide (and Linux does and has for a while) is a "real time priority level". To simplify things a bit, when a process is marked as "real time", that process runs and every other process is ignored. This is important if that process has a task that *must* complete. As a negative side effect, it means that another task (which might only want a tiny bit of CPU time, just enough to keep copying a file from disk to disk) can't run at all and all the disk activity stops. As a result, the time required for all the work the system must do increases, and the system runs more slowly. However, the one process that *must* gets time continues to get it.
It's not something that a desktop or server user is going to benefit much from.
Re:What is Real Time exactly? (Score:2)
Re:What is Real Time exactly? (Score:3, Informative)
Real Time means that you can write a program that is guaranteed to get say 100 CPU cycles every second, without fail, no exceptions. You usually need Real Time OSs when you're writing things like factory robot controllers and other cool stuff like that.
The downside of Real Time is that it can make the system less efficient overall (more time is spent idling the CPU while waiting for a realtime deadline). So for a desktop or a server, there usually isn't any
What Real Time is and what you can do with it. (Score:5, Informative)
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
Soft real-time Vs Hard real-time (Score:5, Informative)
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
Re:Soft real-time Vs Hard real-time (Score:2)
You can't always repeat the event to do another recording.
Re:What Real Time is and what you can do with it. (Score:2)
Audio and video are realtime problems. Unless you have a realtime solution, you will never get rid of dropouts and stutters.
Compare this to Ingo Molnar's 'Voluntary Preempt' (Score:2)
Re:Compare this to Ingo Molnar's 'Voluntary Preemp (Score:5, Informative)
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.
Re:Compare this to Ingo Molnar's 'Voluntary Preemp (Score:2)
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?
Re:Compare this to Ingo Molnar's 'Voluntary Preemp (Score:3, Informative)
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 a
MOD PARENT UP! (Score:1)
Coming soon: SCO vs. Montavista (Score:1)
they can dream (Score:1, Insightful)
Re:they can dream (Score:5, Informative)
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.
Re:they can dream (Score:2)
AFAIK this isn't true.. Do you have links?
Re:they can dream (Score:2)
Re:they can dream (Score:2)
Apparently they have an experimental patch wherein you can boot a "panic" kernel if you get a kernel panic.
Sounds like a neat idea -- configure your UP kernel as the panic kernel for emergency situations. The machine would "reboot" on it's own, much faster than if a watchdog triggered and cycled the power.
Re:they can dream (Score:3, Informative)
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
Re:they can dream (Score:3, Interesting)
RT is useful for data acquisition (Score:2)
Real-time support for 2.6 (Score:5, Informative)
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.
RTLinux vs RT Linux confusion (Score:4, Informative)
multiprocessor (Score:2)
Re:Frist Prost! (Score:5, Funny)
Re:what will LINUX look like in 2010? (Score:1)
and (Score:1)
Re:what will LINUX look like in 2010? (Score:5, Funny)
Re:Wait a sec (Score:2)
Re:Time to be a troll (Score:4, Interesting)
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.
Re:Time to be a troll (Score:2, Funny)
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.
Re:Time to be a troll (Score:5, Informative)
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 [fsmlabs.com] 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!
Re:Time to be a troll (Score:3, Insightful)
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.
Re:Time to be a troll (Score:3, Interesting)
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.
Re:Time to be a troll (Score:3, Insightful)
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,
Re:Responsiveness (Score:2, Interesting)
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 eli
Re:Responsiveness (Score:2)
You've got a choice of about 4 cards if you want to buy a multichannel (more than two channels) sound card for ALSA, and even then it's a pain to configure.
It's happening...but only if you're willing to record everything in Windows first.
Re:So what is the verdict? (Score:5, Insightful)
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.