Slashdot Mirror
Realtime Linux Workshop in Vienna
demachina sent us an EE times article about the realtime Linux conference in Vienna. Attendees decided to endorse the Cygnus EL/IX API for Realtime Linux and to start work on kernel patches.
← Back to Stories (view on slashdot.org)
CE as in Crippled Edition? Or CE as in the last part of "wince"?
Read the article carefully, and ask yourself again about progress . . .
Air traffic control, shipping control (in congested waters think in fog, at night with ice) medical applications,logistics anything where stability and performance are really key.
It's the potential that is important here.
The defence sector's ability to fund your pet (hate) projects keeps other projects that aren't so highly visible afloat.
Linus probably has good reasons to do this. It is most likely impossible to meet all goals in one single source tree. Forking the development process could be a viable solution.
Is there much of a difference between the two?
Of course Linux already runs in real time. What did they think Linux ran in imaginary time, parallel time, backwards time or some other such nonsense? Someone's been watching too much Star Trek. :)
Maybe you'd rather it all "ran" on EmbeddedNT? I know that I , as a prospective "end-user" of such applications, would rather have peer review for the underlying OS, thankyouverymuch.
I have a new department (especially for titles like this...) instead of "from the stuff-to-read dept." it should be
:o)
"from Cmdr Taco and his dangling participles dept."
Well, I guess we should all feel lucky that it's the only thing he's dangling for us
You are buying too much into the QNX marketing crap -- or you are from the QNX marketing team or simply dont know what you are talking about simply parotting what you hear. If QNX with its memory protection was so great all other RTOSES would be dead today, because 99% of them dont provide it. It's tradeoff between speed vs flexibility. It's a design choice. RTLINUX does provide memory protection -- which could be considered, depending on your app more flexible than QNX: Its called user space vs kernel space. All user space processes/threads have memory protection by default of the unix design What RTLINUX gives you is the "Linux curve"; you cant ignore that -- Wall Street does not.
including on-topic info just so that your personal bitching gets moderated up is really low and taking advantage of stupid moderators.
/ k.d / earth trickle / Monkeys vs. Robots Films /
Large print giveth, and the small print taketh away
we're currently converting about 200 Qnx and OS9 machines to a hybrid Linux/Java -- Dos system. The dos machine will act as a microcontroller and I/O interface while the Linux/Java system provides the logic and user interface.
[-- Trust the Monkey --]
As much as I enjoy launching things at people, there are a LOT of other things you can do with a hard RT os.
... that paper is coming down the slot NOW! (and let me tell you these things haul ass!)
... :-)
What I always use as an example of a hard RT system is high-speed check sorter. You have a rigid deadline imposed by the mechanical hardware
If you miss one single deadline you usually (like 99% of the time) end up in a miss-sort situation or something and get to start all over.
Embedding a whole PC with linux on it is an ideal solution to lots of things on sorter. like imaging (Arghh!) and acting as a interface layer between the mainframe controlling the job and the sorter, etc. all the way dow to running the sorter itself.
back to launching things
dv
"There's no secret. You just press the accelerator to the floor and keep turning left." -- Bill Vukovich
You need to understand that realtime doesn't have to mean "realfast". Realtime only means that the system needs to meet a deadline. (though this deadline is frequently a short amount of time from when some event happens ...)
The reason this isn't really applicable for desktop stuff is that you have no true deadlines. I guess you could kludge some stuff like "the system shall redraw my widget within n seconds of a mouse click" or something, but generally there is no need.
On an mostly unrelated note, one thing that makes rt-linux cool is that you CAN run desktop apps on the same box as RT stuff. So you can be controlling a robot arm or something from the same box that your UI is running on. The "rest" of linux runs in the RT kernels idle time.
dv
"There's no secret. You just press the accelerator to the floor and keep turning left." -- Bill Vukovich
...bombs. I still think it's funny that the bomb in The World Is Not Enough (RIP Q) had a nice little `Windows CE' icon on it... Pretty appropriate, though :-)
/* Steinar */
(This comment is of course GPLed.)
Preview your posts, to make sure they don't include a bunch of broken links
Don't post offtopic messages, especially whiny diatribes about how much Slashdot sucks
Don't post messages totally in boldface
Don't italicize bolded text for extra emphasis
Don't use purposely short paragraphs to make your post look longer and more important.
So please, if you're planning on giving feedback to Slashdot in the future, remember that having a poorly-constructed little offtopic cry is probably not the best way to communicate your ideas.
There is some good research out there showing how we can have sane realtime and quality of service guarantees for apps; this is vital for timing critical tasks like burning CDs and videoconferencing; with Linux we should be able to compile kernels safely whilst doing those things. But currently, we're blocked on patches getting into the kernel. Ah well.
Sorry... couldn't resist... =)
It has a new name now, the name of which seems to evade me currently.
In a similar vein, what kind of end-user applications _wouldn't_ benefit from such a real-time operating system. Is there some sort of overhead or any other drawback that would make it non-optimal for simple desktop usage?
"UNIX" is never having to say you're sorry.
is the linux patches at here complient with this API spec?
--
When she told me I was average, she was just being mean.
This is an extremely important even for linux. Its the chance for Linux to enter the hidden world where computers are in use in huge amounts, and few people are aware - in manufacturing environments. However, for robotic and process control, realtime (hard and soft) operating systems are required (as well as embedded systems, which Linux is also maturing into).
:) There's a large amount of Sun boxes (many old enough to be pre-solaris) as well as HP and QNX, which is a cool ass OS no matter how you slice it. A large number of these are old just for the reason that they work fine and are well tested - but an upgrade is imminent.
;)
To have a high profile event like this is a CLEAR and STRONG message to traditional competitors that have controlled this field for years. Hilariously enough a large percentage of the machines are running DOS (its small and old and its bugs are
well known), but the rest are generally unix.
Unbelievably a large amount of this is SCO - the unix world's DOS
What better than getting a system with fully open and free source code? This is almost more important to them than it is to applications users and coders - they need to get into the nitty gritty. Having a viable, stable, popular and open source and $FREE$ real time operating system is
going to catapult linux even further ahead than it already is.
I wonder when the IPOs in this market will start happening.
Conversation with boss ...
... I've been sick about NT crashing all the time. And I heard that Linux is the next big thing. How long is it?
Me: Hey scumbag, there's a conference on Real Time Linux, that I think would improve my capabilities as a developer.
Boss: Hey genius, you're a Windows Developer!
Me: You know the famous saying, "to defeat your enemies you must know your enemy".
Boss: What I never heard that saying.
Me: Ok, Ok. I just made that up. I couln't remember the real saying.
Boss: Hmmm
Me: Its ahhh, thr.. no no, two weeks long.
Boss: Two weeks for a conference? No way.
Me: Its true. Its one of those big conferences like COMDEX.
Boss: Alright where is it?
Me: Ummmm (in a low breath) vienna.
Boss: What was that?
Me (while running out the door) : Vienna!
Ok I have to apologize for the lack of humour in this post.
Man.
Sound support would benefit immensely from hard realtime support in the kernel. Think about it: no more skips/hiccups in your mp3 playback, no matter what the operating system is doing at the time.
Actually, all operating systems should incorporate deterministic schedulers - there's really no excuse not to. Realtime control is something you're going to be hearing more and more about, and not just for factories. Any video game is basically a realtime application, and if you ever wondered why the control in video games sometimes seems to suck and be flakey, it's often because the control isn't implemented with any real time guarantees.
Another example is the proper, dependable detection of such things as double mouse clicks. If you can't guarantee the latency of when the mouse click is handled, you can't be sure you measured the right interval.
The operation of winmodems, much as they suck, could be improved by gauranteed latency interrupt handling, so you can use a small (low latency) buffer and not get errors from delayed interrupt response.
If you look into all the things your computer is doing, you'll find lots of things that could be improved via realtime control.
Life's a bitch but somebody's gotta do it.
More links to the conference (from Linuxtoday):
realtimelinux.org: Realtime Linux Workshop Day 3 Dec 20th, 1999
realtimelinux.org: Realtime Linux Workshop Day 2 Dec 20th, 1999
realtimelinux.org: Real Time Linux Workshop Day 1, Real people, Real place, Real time Dec 18th, 1999
Life's a bitch but somebody's gotta do it.
realtimelinux.org: Realtime Linux Workshop Day 3 Dec 20th, 1999
realtimelinux.org: Realtime Linux Workshop Day 2 Dec 20th, 1999
realtimelinux.org: Real Time Linux Workshop Day 1, Real people, Real place, Real time Dec 18th, 1999
but I have have few questions about this old news: How come I knew about this more than 24 hours ago and I'm just now seeing it on Slashdot?? Please, the stories are starting to lag way behind the news.
Also, some of us read this site in other time zones when the editorial staff at Slashdot seems to be sleeping: You need more editorial staff in other timezones.
One more thing, some of us don't quit reading Slashdot just because everybody at Andover goes home for the weekend: You need some editorial staff that doesn't quit on the weekend.
Life's a bitch but somebody's gotta do it.
Hilariously enough a large percentage of the machines are running DOS (its small and old and its bugs are well known), but the rest are generally unix.
Don't laugh. I developed a big realtime machine control application last year on Dos. Now the application is being redeveloped for Windows NT - requiring a computer 20 times faster, with 16 times more memory and 10 times bigger harddisk. The NT version doesn't do any more, but it does look prettier and supports more hardware.
I'd very much like to develop this application on Linux, but it isn't going to happen this time round, because the support software we need just isn't available. However, I'm willing to predict that by this time next year we'll be looking into how we can do it on Linux, because NT by that time will be seen to suck very apparently in this application, due to bloat, flakiness, lousy documentation of api's and protocols, and miscellaneous licencing issues, to name a few reasons.
Let's see how it goes - in the meantime, I hope that Slashdotters are aware that this is a very key industry for Microsoft and they're pushing very hard to get a dominant position in it. So far, they're doing pretty well, no matter much their software may suck for realtime control. The PHB's just see the pretty colors and wizbang graphics and they're sold.
Life's a bitch but somebody's gotta do it.
it has completed the task before the time allowed in the spec so that is real time OR IS IT .....
could not resist
john
a poor student @ bournemouth uni in the UK (a deltic so please dont moan about spelling but the content)
good of you to set us stright BTW NT's heart is infact just one of digitals research project with cash throwen @ it
GNU hurd is nice but I certianly cant debug it (BTW I can't debug parts of linux now because its just too much ) simple intros make people hack it but yes HURD is nicer
VGA hmm depends on which bios you are programing for yes the standard is there but how much is fudged LOTS !
ah well I just wanted to say THANKS for the informitive post
regards
john
a poor student @ bournemouth uni in the UK (a deltic so please dont moan about spelling but the content)
While sound is a good example, your mp3 playing is more than handled by soft realtime. No one cares about 50ms delay between hitting pause and the sound stopping. Now if you're using your computer as a DSP effects box, 5ms from input soundcard to output soundcard might well be too much. With RT/Linux and David Olofson's RT/Linux audio drivers, we are only limited by the PCI burst size.
Sub-ms audio processing is now doable on Linux. The supposed "Media OS" can't do that. While the BeOS may still kick Linux around in terms of video, between Ingo's low latency patches, RT/Linux, and the new audio plug-in APIs, Linux is now THE OS for audio, at least from a technical standpoint.
If it isn't realtime, it'll burn your toast. :)
Yes, many embedded systems will need to be realtime, if only to make the user interface be really responsive. And yes, I was joking.
Yes. I'm no expert, but from what I've heard, it does add a bit of overhead.
I remember seing something about this posted at the AI labs I think. Glad to see they make progress.
This is really neat for several reasons. It's neat because it represents an expansion in scalability. I think it's very cool that one OS can be so modular, scalable, and configurable that it can run on an embedded controller to run some day to day device, or it can be build into clusters of thousands of nodes to predict weather or prospect for oil.
It is also neat because it is a good foothold. The embedded market is very rough, and even with QNX, WinCE, etc... out there a lot of embedded systems still run _dos_ just because it at least doesn't _interfere_ with the task at hand, although it doesn't offer many OS features. It is nice that there is a new option coming in, that can hopefully use it's adaptability to at least replace all those old messy dos implementations, even if it doesn't displace the other modern embedded systems.
One more thing: embedded systems are not a far shot from wearables. I've been working on building a Linux wearable for a couple years. Right now i'm close (i need a battery pack (in progress), i need to fight the on-board video on my current SBC, and i need to make a cool case, then it should work...), but what i've seen is that every advance in embedded systems (smaller, lower power, etc...) immediately pays off in availability/price of those components, which are pretty much the same for wearables. It's all coming together =:-)
---
Play Six Pack Man. I
Well, advanced robotics and manufacturing automation; automotive applications; aviation; control of laboratory appratus; just about anything which interfaces to the real world by means other than by keyboard and CRT and must control something with consitently low response latency.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
My spin on the desire for Hard Real Time is that many cuurent RT systems need Hard time goals but the underlying "Real Time" OS is anything but and hence the only solution is to throw excess performance at the problem to ensure all things (including non-critical stuff) complete in a timely way. Hard RT should allow leaner hardware to do the same job.
TiVo, IMHO uses "soft" realtime scheduling as opposed to the more rigorous "hard" realtime scheduling in embedded chips.
Actually, I agree with him. I now own stock in ANDN and so I want the company to oblidge to customers requests. Although you may not see a
Ok, back on topic here.
I work for a large company that does embedded systems. Although I personally am not working on any such products, a few of my coworkers are. Some are looking for RT linux to run on a Power PC chip. Right now we are using VX Works and are having tons of problems with the system. We develop the tools on Linux, since Linux has a better interface for tool development then VX Works. We then port the code to VX Works and recompile. The things that go wrong are amazing.
One thing that VX Works does is put global variables into global space. That is, if one process has a global variable X, and another process states "extern X", it then has access to the previous process' X. This is not a security issue since it is an embedded OS, but it can cause crazy debugging if you are not careful and declare two globals with the same name. Although I will say it makes shared memory easier, and thus I believe that was Windrivers' rational.
Steven Rostedt
Steven Rostedt
-- Nevermind
Yeah yeah, and,... and, a share of andover stock for each registered user, and multiple language support, and emailing each user when a new story is added.
Actually, a lot of times stories are posted in the middle of the night, of course, when you consider that the news outlets that Slashdot links to sleep at night(US time), and that I'm sure that the story submissions slow down at night, it makes sense that we don't see 10 new stories posted during the night.
This is an impotant step in the open-source movement. I think many open-source projects fail because of our geek nature. We are proud an many times very individualistic and we often like to start a project and not participate in one already established.
Can this idea of a common API to real-time systems and the union of developers behind a standard be used also in the many different projects of Windows environments based on X?
"Learning, learning, learning - that is the secret of jewish survival" -- Ahad A'Ham
Yes! Hard RT puts severe restrictions on the OS functionality which are not acceptable on the Desktop. One such limitation is virtual memory. There usually is no way to meet the deadline when paging takes place. This is one hardware limit that effects the functionality of a real time system.
It'll be a while before this gets to the microwave and the fridge. You'll see it first in the electric meter, or whatever gateway gets involved with demand-side management. Maybe the air conditioner will wind up doing that part, but the utilities want to put that functionality into the meter to implement time-of-day and market pricing, demand-side management, and a host of other features they want to push from the commercial level down to household customers.
--
Time is Nature's way of keeping everything from happening at once... the bitch.
--
Time is Nature's way of keeping everything from happening at once... the bitch.
Pick this one up at NoBrain.
--
Time is Nature's way of keeping everything from happening at once... the bitch.
How else are you going to build your own Tivo?
Beside launching rockets and killing people, what kind of end-user application would benefit from "hard real-time" support in the linux kernel?
Looking for a great online backup: Green Backup
This is impressive. It's really nice to see free software "work." That being, the right to fork prevents the need to fork. Everyone had the "right" to develop their own version without anyone else's influence, but they decided to get together and pick an API to make it compatible.
Instead of licensing proprietary OSes, Linux based versions should have the advantage of massive peer review and development. While Linux based OSes will no doubt be licensed, it should be a VERY competitive field.
Within a few years, real-time Linux might dominate the embedded market, driving down costs. With everything using embedded systems, the cost savings of not reinventing the wheel will probably allow that "convergence" being hyped everywhere.
All in all, this is a good thing. "Props" to Cygnus for a good job on pulling off the common API... but then, I expect nothing less from Cygnus, but once again proving that RedHat made a smart investment.
This should give Cygnus's embedded Linux a BIG boost, as they know the API better than anyone else. It looks like Redhat will finally have a REAL licensable product instead of a freely copiable one.
Alex
There is a difference between realtime and embedded systems... Last I check realtime had nothing to do with fridges, toasters, or any embedded hardware. Realtime is all about dealing with actual time, embedded deal with non-standard platforms. What am I missing here?
.plan!! what plan?
"The most widely used configuration of RT-Linux offers primitive tasks with only statically allocated memory, no address space protection, a simple fixed priority scheduler with no protection against impossible schedules, hard interrupt disabling and shared memory as the only synchronization primitives between real-time tasks, and a limited range of operations on the FIFO queues connecting real-time tasks to Linux processes. "
The key item to note is that RTLinux does not offer memory protection to real-time processes. This makes it inferior to systems like QNX, which have memory protection for all processes, including drivers. That's why QNX is used for things like nuclear reactor control, train safety systems, medical devices, and other critical applications.
This is not an anti-Linux remark; there's a similar hack for NT that puts a mini-OS under NT, and it has the same problems. I can understand why Linus isn't that thrilled with RTLinux. The right way to do this is to start with a message-passing microkernel and build upward from there, not start with a UNIX-type kernel and build down. I'd like to see an open-source microkernel catch on. The GNU Hurd people were on the right track, but that project seems to be moribund.
The key to doing this right is to have a very, very limited microkernel with fast message-passing. If you do it right, drivers, file systems, and almost everything but message passing and scheduling is outside the kernel and can't crash it. This is how you build systems that work when it matters.
A limitation of such systems is supporting hardware boards that do complicated DMA. Devices that look like channels (SCSI, FireWire, USB, etc.) are fine, but graphics accelerators create problems, as do random ISA and PCI boards that do DMA. Safely managing a device that can store anywhere in physical memory from outside the kernel is tough. QNX generally supports display devices in plain VGA mode for this reason.
..a giant step for mankind. Efforts like these will make sure we have stable microwaves and fridges, running Linux, and not "that CE version of that other OS"...