Re: running real time application behind glade

[José Antonio Sánchez <getaceres gmail com>]

On Tue, 02 Nov 2004 13:29:41 -0500, valdis kletnieks vt edu
<valdis kletnieks vt edu> wrote:
> On Tue, 02 Nov 2004 00:35:33 PST, Aaron Yang said:
>
> >   I'm using glade 2, running on redhat 9. For realtime, it's rtlinux-3.2-pre2
> > running with linux kernel-2.4.20-rtl.
>
> You almost certainly don't need rtlinux here because...
>
> > 2. entry box has a real-time counter counting from 0 onwards in 1 second interval
> >     e.g. 0...1...2...3...

Maybe he is testing the real time kernel to use it on a real time
project. I had to make a lot of dummy tests for my application before
starting with the real work only to get started with the RTAI API. So
this test (if that's a test) it's right.

> If your update gets the in 1.001 seconds rather than 1.000 or 0.999 seconds,
> nothing *breaks*.  You need rtlinux or similar stuff when *stuff breaks* if you
> don't make the scheduling deadline.  I mean, *literally* breaks, as in
> you have to throw stuff in the trash bin. For instance:
>
> If you're burning a CD at 24x and don't have Burn-Free enabled, you *have*
> to have the next several blocks to write into the FIFO in time, or what you
> get is a coaster, not a CD.
>
> If you're doing high-end audio work, you *have* to feed the audio card the
> required number of 96khz samples every second, or you get an over-run or
> a drop-out.  Clicks and pops when you're trying to do professional quality
> audio are *not* considered acceptable.
>
> If you're doing robotic control or something similar, you *have* to measure,
> compute, and adjust the settings on servo motors every N milliseconds, or risk
> dangerous oscillations.
>
> http://www.moog.com/noq/_capabilities__c478/
>
> Yes, it's tossing 15 tons around on those pistons, because you build stuff
> like this on it:
>
> http://www.mfs.com.au/MFS_Motion_Platforms.htm
>
> See those 6 pistons? You *have* to send orders to all 6, *in order*, several
> hundred times a second - and each time you usually need to read the status of
> all 6 actuators, do some involved matrix computations (you can't change the
> length of just one piston, or you *will* break something), and output the
> new commands.  And if you get it wrong, a piston able to move 15 tons
> will try to put itself through the floor of your airplane cockpit simulation....
>
> *Those* are examples of actual "real time" programming....
>
> You may have an easier time of it if you *get rid* of rtlinux if you don't
> *need* it - the flip side of "hard real time" is that it can be *very*
> wasteful of resources, and even cause total starvation of other processes -
> hard real time means that if one process has announced that it *has* to
> run every 50 milliseconds, the kernel may very well decide "Well, it's only
> 9ms till it will want to run again, and there's no realtime processes
> waiting to run, so we're going to just *not* run those non-realtime
> processes just in case one of them will make a system call that takes 11ms
> to return - and we *cant* allow that because somebody else *has* to run
> 9ms from now".

That's not usual. The real time kernel runs below the Linux kernel. In
fact, with RTLinux and RTAI the Linux kernel is some kind of idle
thread, so Linux is executing when it needs and only interrumped by
real time tasks when it's time. No matter if a system call is executed
because all the Linux environment is apart from the real time tasks.

> And yes, when you're doing hard real-time, the kernel *is* allowed to
> drop your GUI dead in its tracks if it feels the need, because the
> X server isn't a real-time process.

Here you are right. There can't be a GUI process in real time. You
need a separate thread (or kernel module) to execute real time tasks.
In fact, a real time task can't make any Linux system call.