Slashdot Mirror
Postcard From The Real-Time Linux Workshop
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.
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?
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!
-bugg
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!!
Ben Schleimer Life is like a sewer, what you get out of it depends on what you put into it.
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.
Win dain a lotica, en vai tu ri silota
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.
Jon Bardin
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.
All that we see or seem is but a dream within a dream.
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
I find it amazing that they're already up to #21. Does anyone know how it all got started?
humor for the clinically insane
great comedy company.
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.
--
Sometimes it's best to just let stupid people be stupid.
uhm .. "realtime" has nothing to do with speed ...
.. the point is, that this request is forfilled !
;)
a real-time os can forfill the action in 2 hours, if it was requested to do so
(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
. . . this online reference might be of interest: The Real-time Linux Quick Reference Guide -- "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."
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.
Mea navis aericumbens anguillis abundat
Why was my post modded down and this one modded up? This guy isn't even saying anything. Slashdot is going to hell and moderators are smoking crack.
All that we see or seem is but a dream within a dream.
Er, not exactly. I was accomplishing the same result in a TCP/IP driver for an FDDI board I wrote for VxWorks 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
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.
--
You're a suburbanite.
There are a number of other free/open source RTOSes for the embedded community. RTEMS (http://www.oarcorp.com/RTEMS) is probably the oldest of these. Other alternatives include eCos (http://sources.redhat.com/ecos) 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.
A deep unwavering belief is a sure sign you're missing something...
Which would be useful, why?
A deep unwavering belief is a sure sign you're missing something...
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.
Goat sex free since 2001
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 (highly recommended, btw) and Integrity, 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 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?
keep up the good work
"It is a greater offense to steal men's labor, than their clothes"
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
Jon Bardin
Near as I can tell he didn't say anything with the slightest relevance to real time computing. Why was he chosen?