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?
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
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.
. . . 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
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
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...
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"
Near as I can tell he didn't say anything with the slightest relevance to real time computing. Why was he chosen?