Slashdot Mirror

← Back to Stories (view on slashdot.org)

RT Linux Patches

Posted by timothy on from the quitcher-laggin dept.

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

5 of 170 comments (clear)

  1. I wonder if it's true real-time by AaronW · · Score: 5, Interesting

    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.
  2. Re:Benefits? by iotaborg · · Score: 5, Interesting

    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.

  3. Re:Benefits? by Nazadus · · Score: 5, Interesting

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

    --
    "Do or do not. There is no try." -- Master Yoda (Half man, half muppet)
  4. Re:Desktop Usage? Why not?! by faragon · · Score: 4, Interesting

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

  5. Re:Benefits? by grozzie2 · · Score: 4, Interesting
    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.