Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Operating Systems Software Linux

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."
This discussion has been archived. No new comments can be posted.

RT Linux Patches

Comments Filter:
  • Desktop Usage? (Score:1, Interesting)

    by Anonymous Coward
    Will this affect desktop usage for the better?
    • Re:Desktop Usage? (Score:3, Informative)

      by meowsqueak ( 599208 )
      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]'...

        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.

      • by faragon ( 789704 ) on Saturday October 09, 2004 @08:34PM (#10482624) Homepage
        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).
    • From the second paragraph of the article...

      Our objective is to enable the Linux 2.6 kernel to be usable for high-performance multi-media applications and for applications requiring very fast, task level reliable control functions.

      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.

  • Benefits? (Score:2, Interesting)

    by 0racle ( 667029 )
    Would the benefits of this be just for embedded devices, or would more traditional uses also benefit from these changes?
    • Re:Benefits? (Score:5, Informative)

      by CaptainFrito ( 599630 ) on Saturday October 09, 2004 @07:25PM (#10482192)
      There are a few non-embedded applications that would indeed benefit. Automated test and measurement is one that I can think of right off the bat. RT probably the last big advantage to VxWorks, so maybe now's a good time to dump your WindRiver stock.
      • 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.
    • Re:Benefits? (Score:5, Interesting)

      by iotaborg ( 167569 ) < minus poet> on Saturday October 09, 2004 @07:26PM (#10482204) Homepage
      It is also very useful in science/engineering fields. At my lab, we use RTAI linux currently, and this allows us to acquire data from our systems in real time, giving us a reliable way to compare our data with time in our systems.
    • Re:Benefits? (Score:5, Informative)

      by mdlbear ( 735185 ) on Saturday October 09, 2004 @07:54PM (#10482399) Journal
      The main beneficiary of the low-latency patches will be multimedia -- audio and video demand consistent scheduling and minimal interference from interrupts. (That's why many audio workstations are still running on Windows 98.)
    • Re:Benefits? (Score:5, Interesting)

      by Nazadus ( 605794 ) <> on Saturday October 09, 2004 @08:15PM (#10482524)
      My employer had to choose Windows over Linux becuase Linux lacked true realtime support. Windows doesn't either, however their is third party software and developing projects is (supposedly) easier with Windows. Our sales dudes also wanted to be able to say "We use Windows!"... We looked at Linux but Linux was just too slow. We are currently moving away from QNX 4.25 (yeah, I know... really old... we are even on the f patch... I finally convinced them to goto g for the server, so I could do backups.. otherwise cp would crash after 64k of files...). We currently build custom industrial robots, so we *have* to have real time or else things could suck. Although I think Linux is a while from where Tenasys InTime (our current third party software) level, it's nice to know people are still working on it... so Linux may become a chance in 8 or so years... when we want to move to another platform. I wonder if the medical field would be intersted in RT Linux... I don't know if they require some special stuff because of legallity or something though...
      • I forgot to add, XP Embedded also allows you to cut stuff out. So the Linux being modular doesn't help very much in this case... (Aside from the monetary value)
      • 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 -
        • Could you give some quantifiable reasons why you think Tenasys is in violation of the RT Linux patent?
          • First, excuse me, it's FSM Labs that owns
            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
        • I suspect your Windows RT provider is in violation of the RT Linux patent.

          FSMLabs, Inc [] owns the RT Linux patent []. Timesys has unrelated technology based on patching the stock kernel, similar to what Montevista does but not as good.

      • Can your robots be hacked, like the register was reporting recently? (see the 32bit vs 8bit /. article for a link: many CDC machines are too underpowered to have any security built in)
    • Re:Benefits? (Score:4, Informative)

      by Samedi1971 ( 194079 ) on Sunday October 10, 2004 @12:31AM (#10483726)
      Commercial flight simulation.

      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)

        by grozzie2 ( 698656 ) on Sunday October 10, 2004 @03:59AM (#10484469)
        hehe, 'not tolerated' is actually a considerable understatement. A Level D sim actually has to be run thru a validation sequence on a daily basis. That sequence must validate that the skew between display motion and platform motion is 100ms or less (its 200 ms for a Level C device). I cant remember offhand the skew allowed between control input and start of motion, but I belive it's also on the order of 'within 200ms of the response of the aircraft being simulated', with the aircraft values taken from in flight measurements. I've been in them a couple of times when the display/motion is out of wack, and it's really quite an awful experience, really the only time I've ever suffered from 'airsick'. 29 years of flying, an airpane has never made me sick, but the simulator has done it 3 times.

        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.

  • Real time? (Score:5, Funny)

    by Eudial ( 590661 ) on Saturday October 09, 2004 @07:19PM (#10482139)
    Does this mean i won't have to adjust my clock any more? ;)
  • Good news, folks (Score:4, Informative)

    by drinkypoo ( 153816 ) <> on Saturday October 09, 2004 @07:20PM (#10482145) Homepage Journal
    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.
    • by WillerZ ( 814133 ) on Saturday October 09, 2004 @07:28PM (#10482217) Homepage
      I, for one, don't like the idea of Linux running as the OS for my engine-management system.

      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)

        by drinkypoo ( 153816 )
        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
        • by WillerZ ( 814133 )
          ...there's very little to go wrong.
          "very little" is more than I want to be going wrong in my car at 70MPH. Phil
          • The issue is that these things are getting more complicated all the time and eventually they're all going to end up using operating systems because the amount of power they use is only going up. The companies are kind enough to segregate your average car's functionality into several separate computer modules because they know that the world is a harsh place and they're cheaper to replace that way but in the interests of reducing the price of the car all of those computers are eventually going to be some tin
            • by WillerZ ( 814133 )
              Not necessarily. Those aren't the only two choices: Realtime Solaris and QNX RTOS are also possibilities. Even better, they could stop trying to add DVD players to my engine-management unit. I don't feel there's anything compelling missing from my current car, which has a number of separate systems and a fairly simple (so far as I can tell) EMU which co-ordinates their efforts,

              The linux ( codebase is not really stable enough to meet the needs of embedded systems. If someone wants to build an
              • While I recognize the validity of your points I do think Linux can be successful even given those considerations. I do not think it is impossible for someone to develop a certified realtime linux for which support costs money, provided they can get sufficient contracts to pay for certification testing. There is still a benefit in that most of the work has been done for them. At this point it's [mostly] bug fixes, testing, and more bug fixes, followed by more testing, et cetera ad infinitum.

                Each new kernel

                • by WillerZ ( 814133 )
                  I agree. It would probably now be easier for a company with an existing RTOS which is massively out-of-date to dump that and fix-up linux, rather than develop their own product further. New entries to the market will still find it very difficult as the path to certification is painful if you haven't trodden it before.

                  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.

      • by WillerZ ( 814133 )
        On a serious note, the design decisions for a general-purpose desktop/server OS are very different than for a safety-critical embedded system like an ECU. There is often no reason to have a pre-emptive multitasking OS in application-specific systems, as they only do one thing.

        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)

          by provolt ( 54870 )
          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'
          • Actually, I think you are a bit confused. LynxOS is NOT Linux. The company (LynuxWorks) sells two operating systems, their own hard-realtime OS (LynxOS) and also Linux. They tend to do a bait-and-switch thing: you bring them in to buy Linux and they try to talk you into using their LynxOS operating system instead. Depending on what you are doing, LynxOS can be a fine hard realtime OS. I just don't appreciate the whole bait-and-switch thing. As for DO178B, (I've worked on a DO178B avionics project) it is in
      • So are you saying that you're a luddite, or that you'd be more comfortable with something like ms windows? (gives a whole new meaning to "crash" and "blue screen of death" doesn't it?)

        Seriously, I can't think of any OS I'd trust more than linux for the really critical stuff.
  • by AaronW ( 33736 ) on Saturday October 09, 2004 @07:23PM (#10482180) Homepage
    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.

    • I hate to respond to my own post, but reading the article (what, someone rtfa) it seems that they did add priority inheritance to the kernel mutexes avoid priority inversion. For proper real-time support, hopefully they also made this available to user-space threads.

    • with Timesys, you can, for example, guarantee that a task will get a minimum of 15.7ms execution time every 31ms.

      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...

    • Be aware that there has been some question weather or not Timesys is violoating the GPL. I don't have the links on me but if you search the LKML for "Timesys" you will find at least a couple of messages questioning their proprietary scheduler work. --adam
      • by Samrobb ( 12731 ) on Sunday October 10, 2004 @02:24PM (#10487018) Homepage Journal

        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 [] 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.

      • Be aware that there has been some question weather or not Timesys is violoating the GPL. I don't have the links on me but if you search the LKML for "Timesys" you will find at least a couple of messages questioning their proprietary scheduler work.

        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.

  • Do you all think these will be merged and ready before 2.6.9 is released?
    • by Anonymous Coward
      When it's tested, and works. And when Al Viro are done with
      his rants over the code.
      My bets are by 2.6.18, any takers ?
    • Hehe I don't think so :)

      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.

    • I don't think the RT Linux patches for the 2.4 series were EVER merged.
  • 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?
    • by Anonymous Coward
      Every video player out there can sync sound and video on linux. If they can do it just fine with today's kernel, why would flash be so special?

      Cleary it's sloppy programming on Macromedia's part.
    • 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 s
  • Does this finally mean Linux will have something like Solaris' gethrtime()?
    • 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.

  • by Elecore ( 784561 ) on Saturday October 09, 2004 @07:38PM (#10482289) Homepage
    Can this be run on my Pentium4? What is it?
    • by 0x0d0a ( 568518 ) on Saturday October 09, 2004 @10:37PM (#10483281) Journal
      Real time refers to a system where tasks completing by a certain deadline is more important than just about anything else. Real time systems are less efficient than non-real-time systems -- they trade efficient scheduling for bounded scheduling.

      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.
    • You could, but you don't want to. RT is normally done in order, and the P4 would be pretty slow if you ripped out the OoOness of it.
    • Can this be run on my Pentium4? What is it?

      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

  • by Anonymous Coward on Saturday October 09, 2004 @07:53PM (#10482393)
    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)

    • by WillerZ ( 814133 ) on Saturday October 09, 2004 @08:40PM (#10482667) Homepage
      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.

    • "It is a nice addition to the linux kernel. Not very usefull for the every-day-workstation"

      Audio and video are realtime problems. Unless you have a realtime solution, you will never get rid of dropouts and stutters.
  • 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?
    • by B1gP4P4Smurf ( 790700 ) <> on Saturday October 09, 2004 @08:19PM (#10482549)
      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.
      • 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?
        • 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 a
      • Excellent commentary. Unfortunately, blocked by /. indentation scheme...
  • 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.
  • they can dream (Score:1, Insightful)

    by quelrods ( 521005 ) *
    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
    • Re:they can dream (Score:5, Informative)

      by drinkypoo ( 153816 ) <> on Saturday October 09, 2004 @08:19PM (#10482552) Homepage Journal

      It would allowing upgrading the OS without rebooting, guaranteed processor time, nearly instant booting, better security, better reliability, and tons more.

      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 sure?

        AFAIK this isn't true.. Do you have links?
        • Sorry, there's so much mailing list crap on the web now that I can't find anything without remembering some better search terms, and compounding the problem is that it's a feature which was introduced several years ago. I remember saying "Gee, that's neat" and moving on because I had no use for it.
    • Re:they can dream (Score:3, Informative)

      by Anonymous Coward
      To be an rtos you usually start with a microkernel

      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)

      by AaronW ( 33736 )
      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.
  • 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.
  • by jd ( 1658 ) <imipak AT yahoo DOT com> on Saturday October 09, 2004 @08:43PM (#10482687) Homepage Journal
    I believe RTAI were the first to produce real-time support for 2.6. Last time I looked, there was some problem with using preempt with RTAI, and it didn't like module versioning. These may have been fixed by now, though.

    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.

  • by Voivod ( 27332 ) < minus poet> on Sunday October 10, 2004 @02:43AM (#10484247)
    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.
  • 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.

Adding manpower to a late software project makes it later. -- F. Brooks, "The Mythical Man-Month"