Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Postcard From The Real-Time Linux Workshop 39

Posted by timothy from the hardcore-vs.-softcore-oops dept.
Kenneth J. Hendrickson writes: "I attended the 2nd Real-Time Linux Workshop this year on November 27-28, 2000 in Orlando, FL. It was held in conjunction with the 21st IEEE Real-Time Systems Symposium. RMS was the Keynote speaker. It was a fantastic event. I have published a report on it at the site of the Melbourne (FL) Linux User's Group." Thanks, Kenneth! This is a well-linked, informative report, and it shows how nicely GNU/Linux (RMS was the keynote speaker) can seep into what has traditionally been a heavily proprietary, expensive field.
This discussion has been archived. No new comments can be posted.

Postcard From The Real-Time Linux Workshop More

Postcard From The Real-Time Linux Workshop

Comments Filter:
  • In our lab, we had a need for hard real time
    digital experiment control. But as the author
    of the paper correctly states, I/O system is
    a source of much latency, so you have to use
    a separate DSP to do control directly to avoid
    bus timing issues. So why would anyone need a
    non-embedded RTOS?
  • In my opinion, you may very well see real-time Linux as the domain of hardware hobbyists, but I have severe doubts it'd make it into professional systems.

    No, I'm not insulting its quality, but I question it's size. How small can you get a real-time linux kernel? In most professional applications, cost is a big issue. If you have only 4k bytes to work with, you'll probably end up writing the routines needed in straight asm for the processor and sending that to the chip.

    I'll be watching how this product develops, and especially take notes of where it is deployed. Good luck, and don't forget to enjoy your work!

  • Is this good/bad/ok for real life applications?

    Very good.

    Whats the performance of other RTOSs?

    Depends on the CPU (duh!) but about that. This is in the neighborhood of context switch time, which is where it needs to be for a RTOS. The important thing is that it's an order of magnitude better than the scheduler clock, which is the latency you're pretty much stuck at if you don't have a RTOS.

    Rev. Bob "Bob" Crispen

  • In the RTL performance paper,
    the author says that both RTAI and RTL
    have a worst-case performance of 17-19 us.

    Is this good/bad/ok for real life applications?

    Whats the performance of other RTOSs?
    Thanks!!

  • If you pronounce GNU without the hard G, how does anyone understand what you're referring to? The adjective "new" would often fit in the same context.
    --
    Obfuscated e-mail addresses won't stop sadistic 12-year-old ACs.
  • So why would anyone need a non-embedded RTOS?
    • So you can run the whole thing on one box.
    • So you don't have to fool with loading the I/O software onto the Big Box O' I/O
    • So you can debug easily (in-system software debuggers instead of ICEs)
    • So you can reduce your latency between the I/O box and the main box.
    • So you can run applications on your main box instantly when you get a particular I/O event.
    • So your I/O system can do high-level-ish stuff itself.
    Rev. Bob "Bob" Crispen
  • actually your an anonymous coward I am Jon Bardin and my dorm phone number at USF 813-905-8576, try not to bother my family at my old phone number. so anonymous coward, how long did it take you to develop such 31337 skillz like looking up my name on some yellow page search engine how about trying to hack my box at sig.mine.nu hell i will even tell you the root password its 'qwerty' and show me how 1337 you really are, our cant you figure out how to run telnet in your winblowz box or is it past your bed time.
  • 1. Why?
    2. Reducible to typing one word on command line.
    3. When timing is critical, people hand code in
    assembly.
    4. Your "I/O box" should be powerful enough to
    rarely call main box. Latency?
    5. Write your apps for "I/O box".
    6. see 4.
  • Please lay off the crack. How is this redundant? No one else has asked this question, and I really wanted an answer. But now that it has been modded all to hell no one will read it, and no one will answer my question. Thanks a lot.
  • I've used it in two commercial systems. Both were VME chassis control systems with several single board computers. The x86 boards each had 8 MB nonvolatile RAM. Worked great. The whole "embedded" label is pretty nebulous, but for the type of system you're talking about, I agree with you. In those cases you would usually roll your own OS, if you use one at all.

  • Re:OK, I'll bite: (Score:3)

    by revbob ( 155074 ) on Sunday December 10, 2000 @08:20PM (#568453) Homepage Journal
    This isn't exactly responsive to your question, but here's one of my favorite definitions, from the DoD Glossary of Modeling & Simulation Terms [dmso.mil]:
    Real-Time System: A system that computes its results as quickly as they are needed by a real-world system. Such a system responds quickly enough that there is no perceptible delay to the human observer. In general use, the term is often perverted to mean within the patience and tolerance of a human user.
    The Jargon File says:
    real time 1. [techspeak] adj. Describes an application which requires a program to respond to stimuli within some small upper limit of response time (typically milli- or microseconds). Process control at a chemical plant is the {canonical} example. Such applications often require special operating systems (because everything else must take a back seat to response time) and speed-tuned hardware. 2. adv. In jargon, refers to doing something while people are watching or waiting. "I asked her how to find the calling procedure's program counter on the stack and she came up with an algorithm in real time."
    Rev. Bob "Bob" Crispen

  • Sir (or Madame), you've made my day. I haven't laughed so hard in a long, long time.

    Thanks for brightening my day.

    (No, that's not sarcasm. I'm serious)

    J. T. "Mac" MacLeod

  • To build a MIDI-controllable programmable modular software synthesizer (for sound, you know) on consumer boxes ? You need very low latency to have it behave like a real instrument. Computers are getting fast enough for all kinds of funky media experiments.

    How about running a virtual reality system on a PC box ? I'd say that qualifies as a time-critical app, especially if you're doing measurements at the same time. I'd like to have graphics that can be _guaranteed_ not to skip frames under any circumstances. If not for any other reason, science requires reproducible results.

  • It was held in conjunction with the 21st IEEE Real-Time Systems Symposium.

    I find it amazing that they're already up to #21. Does anyone know how it all got started?


    1. humor for the clinically insane [mikegallay.com]
  • I'm not sure what the author of the paper intended. There are indeed a bunch of RTOSes already that offer memory protection, provided they're run on a chip with a decent MMU (QNX, OSE, VxWorks etc. on a PowerPC or Intel >=386, for example).

    You could argue that the process of doing table lookups for each memory access makes things less "real-time", but unless you're dealing with a really slow/primitive chip (which, remember, a lot of older RTOSes had to do...), it shouldn't be too much of an issue...

  • I attended the 2nd Real-Time Linux Workshop this year on November 27-28, 2000 in Orlando, FL...

    Wait, you're telling me that RMS attended an event with Linux in the name rather than GNU/Linux, and he didn't a) boycott the event, or b) demand they change the name before he would appear?

    Clearly this was NOT the real RMS, and was an alien imposter.


    --

  • uhm .. "realtime" has nothing to do with speed ...

    a real-time os can forfill the action in 2 hours, if it was requested to do so .. the point is, that this request is forfilled !
    (i.e. i need those nuke-sensor-informations processed in x ms, or they are gone ;)
    the "x" is not important, it is important that the request is forfilled !


    Samba Information HQ
  • I guess they call it "Real-Time Linux" and not "Real-Time GNU/Linux" because everything in the RTOS is very much about the kernel itself, Linux.

    Personnally I rarely put GNU in front of Linux but it's just a bad habit...


    --
  • I'm sorry, but I think you may be mistaken. We use VxWorks on PPC chips every day here and it is not uncommon for a single task to take down the entire system. As far as I know, VxWorks does not have memory protection on any platform. This is a trade off that allows them to have extremely fast context switches.
  • Strike a blow against RMS idiocy: pronounce GNU and Gnome without the hard G.

    I'm glad to find that I'm not the only one who is irritated to death by this nonsense.


    "Homo sum: humani nil a me alienum puto"
    (I am a man: nothing human is alien to me)

  • Re:Is RMS going soft?? (Score:1)

    by Anonymous Coward
    Real Time Linux is mostly a matter of the kernel (here: linux). So RMS pointed out explicitly that "GNU/" is not missing :-)
  • . . . this online reference might be of interest: The Real-time Linux Quick Reference Guide [linuxdevices.com] -- "a handy index of distributions and implementations of the Linux kernel, Linux add-ons, and other software that support the enhanced responsiveness required for process control, high speed communications, streaming media, and other real-time applications."
  • The standing on one foot answer:

    A real-time operating system is an operating system that can offer timing guarantees to applications. Real-time is not the same thing as real fast. Determinism is more important than speed.

  • Why was my post [slashdot.org] modded down and this one modded up? This guy isn't even saying anything. Slashdot is going to hell and moderators are smoking crack.

  • The first RTOS to offer this capability? (Score:3)

    by revbob ( 155074 ) on Sunday December 10, 2000 @06:48PM (#568467) Homepage Journal
    A goal for the near-term future is to be able to run real-time tasks in userland with all of the memory protections provided by unix, on all real-time Linux variants. Emanuele Bianchi has already done this on RTAI! Real-time Linux (as far as I know) is the first real-time OS to offer this capability.

    Er, not exactly. I was accomplishing the same result in a TCP/IP driver for an FDDI board I wrote for VxWorks [wrs.com] back in 1990.

    Basically, you do at real interrupt level what you need to do there and stuff the functions that don't need to be done at real interrupt level into a ring buffer which then feeds a high priority task that fetches the function calls off its ring buffer one by one and executes them. As you exit your driver you call for a scheduling event. Because you can set hard, non-degrading task priorities, your cleanup task inevitably runs immediately. Other arriving messages are pretty much a don't-care (they interrupt the high-priority task), so long as you don't swamp your CPU with messages.

    For example, suppose you get a device interrupt from your network board. At real interrupt level you check to see if a packet has arrived, and if it has, you stuff it into mbufs (actually, clusters). You queue the rest of the packet processing (e.g., the IP function table calls) for your high priority "cleanup" task, and you call high-level stuff like non-blocking select() in your application.

    If you start off with a BSD-style driver, it's pretty easy to figure out what absolutely has to happen at real interrupt level and what can be thrown to a high priority task.

    Being able to write our own driver came in very handy, because we used a broadcast message over FDDI as a synchronization event. All the applications signed up a function that did a taskResume on their main executive whenever that message arrived. The high priority task checked each incoming message to see if anybody had signed up to run something when it arrived, and if so, ran it (probably by sticking it into the ring buffer for the next-highest priority task -- can't remember any more -- maybe I just ran it then).

    On a later version we got rid of some of the overhead by making the resumer function give a semaphore and had the executive wait for the semaphore at the bottom of its main loop. Since semaphores were queued, even if an application overran its time slot, it wouldn't lose a frame (within reason).

    It's good to see that real time Linux seems to climbing up to where it can stand alongside the RTOSs, and, having had a source license for VxWorks, I can testify that having source on hand makes a real difference in a crunch, not only to fix bugs, but to figure out work-arounds. Nobody's documentation is ever good enough, and the source code never lies.

    Rev. Bob "Bob" Crispen

  • Strike a blow against RMS idiocy: pronounce GNU and Gnome without the hard G.
    I'm glad to find that I'm not the only one who is irritated to death by this nonsense.

    You're nuts, the pair of you. If you believe that people should use the de-facto names for things, then why are you trying to rename a well-known operating system to "Noo"?
  • Yes. The request must be fulfilled or it must fail. Also, the request must take a fixed amount of time to complete. That time can indeed be rather long, although it's probably not very common.
    --
  • There are a number of other free/open source RTOSes for the embedded community. RTEMS (http://www.oarcorp.com/RTEMS [oarcorp.com]) is probably the oldest of these. Other alternatives include eCos (http://sources.redhat.com/ecos [redhat.com]) and uCOS (no URL handy).

    Disclaimer: I am one of the original authors and current maintainer of RTEMS. :)
  • Actually, if you read the docs, the context switch time for QNX is around 1.95 microseconds on a P100, and the interupt latency is something like 4.5 microseconds.
  • Which would be useful, why?
  • Because g-nu does't sound much less silly?
  • Because g-nu does't sound much less silly?

    Ah, obviously regional differences are cutting in. In Britain, "new" is pronounced "nyoo". Hence there is no such word as "noo"[*] and it sounds as silly as "boing".


    [*] since the 1950's, "g-noo" has been the preferred pronounciation of "gnu" as in the animal, due in part to Flanders and Swann's "gnu song".

  • is step INTO your software and SEIZE the hardware interrupt controller, so if the software fscks up and would like to shut stuff down or freeze things, Realtime Linux takes over and executes Mr. Software's tasks in realtime.

    If there is a bug in the code of Mr. Software, the flipside is that the realtime capability will crash your system immediately.

    from the paper:

    "A goal for the near-term future is to be able to run real-time tasks in userland with all of the memory protections provided by unix, on all real-time Linux variants. Emanuele Bianchi has already done this on RTAI! Real-time Linux (as far as I know) is the first real-time OS to offer this capability."

    How do they intend to do this? (I am clue-free. I admit it. ;)

  • Memory protection possible in a RTOS? (Score:3)

    by ActMatrix ( 246577 ) on Sunday December 10, 2000 @03:10PM (#568476) Homepage

    The article states "The real-time portions of a system run in kernel space in real-time Linux. Therefore, no memory protection can be offered. ... (Note: this disadvantage also exists for all other real-time OSes as well...)

    Is this really true? I'm no expert on real time operating systems, but I do know that several claim to have some memory protection, including QNX [qnx.com] (highly recommended, btw) and Integrity [ghs.com], which I haven't tried. Perhaps I'm missing something, or is this report over-generalizing?
    ---

  • It's nice to see some impressive displays of Open Source Real Time Systems - the Fantazein clock [fantazein.com] is an especially nice demo. Are there any other Open Source RTS projects in development, and can anyone post some links to them if there are?
  • It is good to see a technology succeed based on its' own merits rather than through the force of superior and overwhelming marketing.

    keep up the good work

  • Mlinux is my hometown LYG an di am vry happy to see it make some major headlines way to go and props to all the LUG members, and an extra congrats to Ken. btw tony how is the server holding up ;) cya over xmas break -Jon
  • Near as I can tell he didn't say anything with the slightest relevance to real time computing. Why was he chosen?

  • (Score:1)

    by Anonymous Coward
    [gnushit.org]

Slashdot Top Deals

The use of anthropomorphic terminology when dealing with computing systems is a symptom of professional immaturity. -- Edsger Dijkstra

Close