Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Realtime Linux Workshop in Vienna 64

Posted by CmdrTaco from the stuff-to-read dept.
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.
This discussion has been archived. No new comments can be posted.

Realtime Linux Workshop in Vienna More

Realtime Linux Workshop in Vienna

Comments Filter:
  • including on-topic info just so that your personal bitching gets moderated up is really low and taking advantage of stupid moderators.

  • 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.

  • As much as I enjoy launching things at people, there are a LOT of other things you can do with a hard RT os.

    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 ... that paper is coming down the slot NOW! (and let me tell you these things haul ass!)

    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
  • 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
  • ...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 */
  • Comment removed based on user account deletion
  • The things needed for realtime (the utime patch from Kansas, etc) don't seem to be taken seriously by Linus, AFAICS.

    There is some good research [cam.ac.uk] 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.

  • A realtime conference? Is it... going on right now?

    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?
  • is the linux patches at here [rtlinux.org] complient with this API spec?
    --
  • well its not going on right now, but it will starting EXACTLY on time, and will run EXACTLY as long as planned. no more (soft) and no less (hard).

    :)

    Math

  • RTL - Unrefutable proof of Linux's maturity (Score:4)

    by mathboy ( 10519 ) on Wednesday December 22, 1999 @06:35AM (#1452478)
    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).

    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 :) 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.

    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 ...

    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 ... 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: 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.
  • Oops... sorry for those broken *relative* links... here they are again. *blush*

    More links to the conference (from Linuxtoday):

    realtimelinux.org: Realtime Linux Workshop Day 3 [linuxtoday.com] Dec 20th, 1999

    realtimelinux.org: Realtime Linux Workshop Day 2 [linuxtoday.com] Dec 20th, 1999

    realtimelinux.org: Real Time Linux Workshop Day 1, Real people, Real place, Real time [linuxtoday.com] Dec 18th, 1999

  • More links to the conference (Score:3)

    by SurfsUp ( 11523 ) on Wednesday December 22, 1999 @07:20AM (#1452482)
    More links to the conference (from Linuxtoday):

    realtimelinux.org: Realtime Linux Workshop Day 3 [slashdot.org] Dec 20th, 1999

    realtimelinux.org: Realtime Linux Workshop Day 2 [slashdot.org] Dec 20th, 1999

    realtimelinux.org: Real Time Linux Workshop Day 1, Real people, Real place, Real time [slashdot.org] 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.

  • Realtime on Dos - don't laugh (Score:3)

    by SurfsUp ( 11523 ) on Wednesday December 22, 1999 @07:48AM (#1452483)
    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.
  • 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)
  • Interesting. Unless the DOS and linux boxes need to by physically seperated, this is precisely what RT/Linux is for. It is basically a simple DOS like environment that runs Linux in whatever time is left over. You can get interrupt response and scheduling very similar to DOS, and communication with tasks in the Linux subenvironment is quite simple using shared memory, or FIFOs. I can't help but think it would be cheaper to just use one machine running RT/Linux unless you already have a large investment in the DOS portion.

    RT/Linux in effect gives you two machines, one RT system running a simple (but richer than DOS) environment, and then a normal linux environment.
  • 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.
  • The kind of realtime needed for video is easily handled by Ingo's small low latency patch, and SCHED_FIFO. The kind of realtime needed for real time audio processing is beyond what UTIME (or KURT) can deliver. You need a sound driver framework for RT/Linux for that, which David Olofson has provided.

    So UTIME, while interesting for network traffic analysis applications, is too much for realtime video, and not enough for realtime audio. Two different solutions, each with less overhead in the normal case, are available, and will make their way into the mainline kernel.
  • 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 =:-)
  • 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.

  • 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.
  • you need to balance "hard" realtime and "soft" realtime. burning CD's is "soft" realtime with the cd drives buffers and videoconferencing is a "soft" realtime as well (since no one dies if a frame is missed). The "hard" realtime stuff is mainly for embedded apps - *not* your average desktop application which can do well enough with "soft" realtime. No one dies if your app doesnt make a deadline - but the same is not the case for embedded controllers.

  • 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 /. poster as a customer, but the more users read /. the more revenue they can get.

    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
  • 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?
  • s there some sort of overhead or any other drawback that would make it non-optimal for simple desktop usage?

    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.
    --
  • Is there some sort of overhead or any other drawback that would make it non-optimal for simple desktop usage?
    Overhead is one thing (guaranteeing that a task can get X% of the CPU with Y microseconds of latency requires more task switches). Another is that the desktop system probably wants to devote more CPU to the task that's got user focus. Yet another thing is that most RTOS's assume that all programs are well-behaved and will relinquish the CPU when they have nothing to do, allowing lower-priority tasks to run; in a desktop application environment this assumption is probably invalid for a large subset of systems.
    --
  • Science fiction author Vernor Vinge will be touring the USA and Canada over the next month to promote his new book, Marooned in Real-Time Linux.Set in the early 21st century, it follows several angst-ridden Windows programmers after Y2K bugs and the subsequent legal action have led to a post-Microsoft world.Their skills having been frozen by years on the upgrade treadmill, they emerge into a scene where they are anachronisms.Their varying fates work as a cautionary tale in this time of rapid technological advance.

    Pick this one up at NoBrain [slashdot.org].
    --

  • 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?
  • 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
  • Beside launching rockets and killing people, what kind of end-user application would benefit from "hard real-time" support in the linux kernel?

    Air Traffic control would be one. A delay of even a second or two in updating the information would be bad. Coordinating large scale movements of people, in any sort of organization, could be useful. Whether it is infantry in the field or search parties trying to find a lost hiker, real time computing can be beneficial.
  • 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?
  • You know, even though you probably just meant that as a joke, it makes sense to me... I guess embedded systems will need to be realtime in many cases. I still stand by the fact that they are also two seperate ideas though.
  • Any communication with actual physical hardware is very timing-critical. Just as you need realtime guarantees in order to make your missile hit its target, a tape drive or CDR needs to be provided with data at a particular rate in order to dump those bits onto the media as it passes.

    Of course, many really nasty timing-critical tasks like moving graphics data to your video card, or (link-layer) network traffic processing are handled by carefully crafted interrupt handlers, the firmware on your NIC, etc. But more complex tasks (burning a CD, for instance) simply cannot be done at that level.
    Applications that directly control mechanical processes (for manufacturing, teledildonics, whatever) generally require this kind of precision. This is a requirement for many embedded applications, and is thus necessary if Linux is to be usefull outside of the catch-all realm of desktop PCs.
  • RTLinux is, unfortunately, a hack, not a solid real-time OS like QNX [qnx.com]. From The RT-Linux approach to real time:" [nmt.edu]
    "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 [mit.edu] 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.

  • I think so, and with mutual support.

    "One advantage attendees liked was flexibility. EL/IX is still open to revisions, which workshop attendees felt gave them the opportunity to tailor the API to meet their needs. "

    This should allow all to at least get a foot in the door to have input on the "Standard".

  • ..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"...
  • No, actually all these claims that real-time imposes a lot of additional overhead are totally false, or at least not necessarily true by any means. Real-time systems have to compete on response time, and you don't get response time any better by slowing things down.

    Back when I was at Lynx (a long long long time ago), we benchmarked simple things like round-trips into the kernel versus SVR3 (the current competitor) and noted that our kernel was at least 10 times faster. User experience bore out the tests, as Lynx in use was just tremendously faster than System V.

    The main problem with real-time systems is that the preemptive scheduler is not tuned for "multi user" or "time sharing" behavior. If a high-priority task gets the CPU, then it gets it completely. As long as it doesn't block, the kernel will only preempt it for higher-priority threads. That's not necessarily what you want in a general-purpose server, but on the other hand a web server might actually benefit (assuming somebody took the time to configure the system appropriately).

  • You don't want to guarantee that a task gets X% of the CPU. That's not usually the way a real-time system works. What you want to do is guarantee that an event can be responded to within a well-defined maximum time window. That translates into the kernel being able to preempt a running thread and start up a waiting thread as fast as possible.

    To do that, it's necessary to minimize the amount of time spent in hardware-locked interrupt routines. The kernel can't context switch while it's handling a low-level interrupt. You therefore have to get out of those as quickly as possible and transfer control to a thread that does the bulk of the handler work.

    Context switching in real-time systems is generally an area of great optimization, since it reduces the maximum response time.
  • The key to doing this right is to have a very, very limited microkernel with fast message-passing.

    Well, that's certainly the QNX way of doing things, but I think it's a stretch to call it "the key".

  • The api for RTLinux is still evolving and I want to make sure that current RTLinux users don't get too worried about the resolutions of a group of users of RTLinux and other flavors of "real time" on Linux. For us, backwards compatibility and performance are essential and I am not yet convinced that the Cygnus API is such an advance. RTLinux, however, supports the main API as part of a scheduler module and I look forward to seeing proof of concept in an EL/IX module.
  • I think the microkernel versus monolithic kernel technical argument has been long since lost by the microkernel people. RTLinux offers no memory protection for RT tasks because the RTLinux design calls for putting only the absolute necessary RT components on the RT side and making those as absolutely low overhead as possible. QNX has a different model, and QNX is a very good system, but they have a harder time providing good worst case timings. For machine control, worst case, not typical case, is the number that is interesting.

Slashdot Top Deals

It's a naive, domestic operating system without any breeding, but I think you'll be amused by its presumption.

Close