Slashdot Mirror
Papers On Real-Time And Embedded Linux
An anonymous reader writes "LinuxDevices has once again published the proceedings of the annual Real-Time Linux Workshop. This one, the seventh, was held in France earlier this month, at the University for Science and Technology of Lille (USTL). The papers span a range of topics, from fundamental real-time technologies to applications, hardware, and tools. Enjoy!"
I've always found the field of embedded operating system's somewhat intruiging. From the automatic welders, to the VCRs, etc. Anything involving robots, or extremely low power systems is somewhat interesting, and even if linux eventually fails on the desktop market (stops growing), it may be around us in our daily lives much longer.
Help Fight SPAM today!
This has already been modded as a troll, but giving you the benefit of the doubt, do you mean something different from things like Monta Vista or Lynuxworks ?
Of course, it's also worth mentioning that "real time" doesn't necessarily mean "fast." In fact, rather the opposite is typically true: a real-time system must (by nature) make the worst case predictable -- but often compromises the average performance to do so.
--
The universe is a figment of its own imagination.
The universe is a figment of its own imagination.
dont forget the lowly event loop. alot of embedded
systems dont need anything like an os at all.
Embedded devices aren't really focus market for linux. Even with being stripped to bare minimum, the kernel will take over 500kb to operate.
Embedded systems usually don't have need to carry that much memory. Task specific operating systems like TRON and its variations take only few kilobytes, and are extremely efficient and reliable in what they do.
What linux provides, is interesting approach, but it also rises the price tag with hardware specs higher than the cheapest alternatives.
There are no atheists when recovering from tape backup.
Because those better alternatives provide more freedom for Microsoft to take the code, repackage it, hack it about as they wish and sell it to the masses, giving fuck-all back to the community. This would likely bother a few of the developers in question.
For the love of God, please learn to spell "ridiculous"!!!
Why do embedded developers continue to imprison themselves in the GPL trap by using Linux,
Because Linux has a much bigger developer comunity and you can get commercial support targeted at embedded development from several vendors. Giving better freedom getting developer resources.
And the GPL "trap" as you call it, does not really matter even in embedded development. The interesting part of the product, or the part you may want not to GPL, will reside in userspace anyway making the GPL of the kernel irrelevant.
QNX isn't a Linux derivative. It's not even a UNIX derivative. It's a POSIX-compliant microkernel, with a totally different underlying architecture than Linux. Latency is much better than Linux, because the kernel just handles message passing, CPU dispatching, and timing - everything else, like file systems, drivers, and networking, is in user space and preemptable. Overall performance is slightly worse than Linux.
The newer real-time Linux variants based on the 2.6 kernel are getting to be decent. 2.6 finally got most of the long interrupt lockouts out of the kernel, and allowed preemption of some kernel tasks. Look at the MonteVista or BlueCat variants. You still have to be careful not to load any drivers that contain long interrupt lockouts, or real-time latency will go way up.
The original "RT Linux" was a hack which basically allowed running your real-time application as a loadable kernel module, like a driver. That's basically a dead end at this point in time.
QNX, unfortunately, was acquired by a larger company, which has changed the business strategy from opening up QNX to raising prices and cutting functionality of the base package. The main architect of QNX died a few years ago, and things really haven't been the same since. It's sad.
I suppose I'll get modded as troll (again) for saying so, but from what you've said, I'd guess you're one of the people who's not an RT programmer.
Real-time programs do need to react in real time. A typical example is that the program needs to react within X microseconds of an interrupt happening. A hard real-time requirement is exactly that -- no "seem that they do" about it. For example, a navigation system for an aircraft must react within the right amount of time to input from the pilot, radars, etc. A late reaction carries the possibility of killing hundreds of people (conceivably even thousands with particularly bad luck about where it lands).
Every system has some delay -- the questions are 1) how much?, and 2) how much does it matter if it misses its window by some small amount? A hard real-time system is one where you have an absolute maximum delay, and you must never miss it. A soft real-time system is one where you may be able to get away with slightly greater delays on rare occasion -- the "softness" of the real time being determined largely by how large the delay can be, and how often it can happen. The situations above with brakes or aircraft navigation are about as hard of real-time as you can get -- excessive delay is likely to cause deaths. A router or mail server has substantially softer requirements. If it misses receiving part of a packet very often, it won't work well -- but as long as it's not very often, it's probably not a problem, and endangering lives is pretty far-fetched even at worst.
Also note that real-time does not necessarily mean much about being fast. Years ago, I worked on some software to control some of the operations in a sewage plant. In most cases, the computers' requirements on the reaction times were measured in entire seconds and sometimes even minutes -- but if it missed a deadline, millions of dollars in damage could be expected, and endangering lives was possible as well. Ridiculously slow by most standards, but hard real-time nonetheless.
So -- the essence of real-time is not about "high speed" it's about "dependable and predictable speed". Real-time requirements are specified not only in terms of "How fast?", but "How serious is too slow a reaction?" -- and the latter is often what really dominates.
--
The universe is a figment of its own imagination.
The universe is a figment of its own imagination.
And the FreeBSD ports system is far superior to the Gentoo equivalent.
/usr/ports/whatthefuckdirisitin/gaim ; make install
O RLY?
Gentoo: emerge -UD gaim
FreeBSD: cd
Yeah that's SOOO superior.
Gentoo uses mirrors for fetching files. BSD apparently doesn't [I couldn't fetch mplayer because the primary server was down].
Gentoo uses bash, BSD uses csh [WHY!!! OH WHY!!!]
Try installing more complicated packages like latex, I installed all of the laTeX* packages and I still didn't have a "latex" command.
As for cpu scaling, it's an AMD XP-M laptop with ACPI based PST entries. with "cpufreq" loaded the cpu runs at the full speed of 1.8Ghz regardless of idle time. In Gentoo Linux [well just linux 2.6.x] scaling works and the cpu idles at 530Mhz.
Agreed I didn't use it for long but I just don't see the appeal OVER gentoo. I mean Gentoo can be a server OS just the same as BSD. In fact, I've built quite a few live HTTP, SMTP, POP, IMAP, NIS, DNS servers from it. I'm sure BSD is up there but it lacks polish. People bitch that gentoo is hard to use, how is BSD any better when it's even harder to use?
Gentoo ain't perfect [nor is the Linux Kernel] but for the most part it works a lot more than it fails [being that all of my computers run it]. I think it's good that BSD distros exist because it provides diversity in case for instance, Linux blows up.
All I'm saying is FreeBSD requires some serious userspace polishing.
Tom
Someday, I'll have a real sig.
"How about if you try to look into facts before shooting your mouth off?"
I'm not an expert in RT java, but I've written code with required timing accuracy to 1 cpu cycle which I think qualifies me quite well to comment on RT issues.
"What's important is that if you have a specific architecture you need to know, exactly, what delays occur and that they have upper bounds."
The issue isn't speed, it's accuracy. Hard RT systems have lower bounds as well as upper bounds. Being early is no better than being late.
"The same would be true with a Asm or C RT system"
Sure, but the difference is that in Java you have another layer to deal with so determining the timing is more complex.
"The main reason you'd want to run Java RT is because first off, it's faster to write correctly."
This is a matter of opinion even for conventional programs. For a RT system, I think you have the burden of proof for this claim.