Re: [rtl] Newbie ?

[David Olofson <david.olofson@reologica.se>]

On Tuesday 06 November 2001 13:36, Mark Hounschell wrote:
> I/we have an app (heavily threaded) that is an emulation of a
> proprietary real-time OS. We have recently ported it to linux. It
> requires a number of pci cards that have been designed
> to accomodate some of the hardware that this proprietary OS ran on. The
> linux drivers for these are mostly complete and working. We have found
> by way of interrupt latency/determinism
> tests that run under the emulated OS and on the native
> hardware/proprietary OS that the determinism numbers we get under the
> emulation are quite poor compared to the real/native environment. I'm
> sure this is no suprise to anyone, even us. It was expected. In the
> native
> environment from interrupt time to user code start time (latency) we
> get 60us with a variance
> of 1us (determinism). I know 60us isn't so greate, it was for it's time
> though, but the 1us
> variance is excelant and what we need. The numbers for the same tests
> run on a dual 1.7gz p4 zeon are about 50us latency but the determism
> depends on alot of things. If we run the app
> in single user mode the variance (determinism) numbers are almost
> exceptable (but not really).
> They end up around 100us in single user mode. They are 2-45 ms with X
> running which is crazy.
> A simple move of the mouse causes the numbers to go into never never
> land. With no X (run level 3) the numbers are better but still very
> unexceptable.

Of course. Standard Linux is a server OS, not a real time OS!

You have to use Linux/lowlatency, kpreempt or similar patches to achieve 
anything like real time performance in user space, and even then, it's 
very unlikely that you'll get that kind of figures for worst case. Even 
kpreempt has to honor kernel spinlocks, which can be held for a lot 
longer than 60 µs.


> Why I am posting is, we want to try rtlinux to see what it gets us. I
> have installed the 3.1
> version for the 2.4.4 kernel and did the suggested method of making
> mk.rtl available to our
> makefiles for the app compile. It didn't change anything. I need to
> figure out if there is an
> easy way to make our app look like real-time to rtlinux. I've looked at
> the rtlinux API and
> many of the stanard linux calls are available and I assume they are
> different but with the
> same names. I'm not a C programmer. I'm an old fortran/assembler guy
> from the days of this
> old proprietary OS. IS there an easy way for me to try rtlinux for this
> app such that it doesn't have to be rewritten.

Provided your application doesn't depend on other services than pthreads 
and your own drivers, it should be possible to port it to RTLinux with a 
reasonable amount of work. There are also RTLinux drivers for various 
hardware, including network devices (with RT protocol stacks), so even 
that should be relatively easy to handle.

If you need dynamic memory allocation and other "nasty" stuff (which 
seems to be getting more and more popular these days, even in so called 
hard real time applications), there might be more work to do. You can use 
preallocated pools of fixed size objects - if you aren't already.

For "true" dynamic allocation (ie malloc(<any reasonable block size>)), 
you may look at RTAI, which provides such a solution. (Included in the 
RTAI distro, I think.)


> What about our drivers that we had to write for linux?
> Is there anything that will have to be done to them?

The ones that *must* run with real time perormance will have to be ported 
to RTlinux. (Which in this case, probably would involve replacing some 
sync constructs and using the rtl_posixio layer instead of the Linux 
kernel register_chrdev() and co.)

Drivers for buffered, soft real time I/O (such as writing stuff to disk 
or screen) can be done with the standard drivers. The simplest way is 
probably to communicate with user space (using RTL FIFOs and/or shared 
memory), and do the I/O from there.

With a user space real time patch in combination with RTL, you can also 
move "firm" real time stuff, such as real time graphics rendering, to 
user space. (Which in that particular example, would simplify things a 
*lot* - software rendering directly to VRAM from within RTL is doable, 
but imagine porting a full OpenGL implementation to RTL... *heh*)


> Does one have to be a linux
> kernel hacker to make an app run in real-time under rtlinux?

Well, that depends on what you need to do... *Anything* is possible - 
it's just a matter of how deep you're willing to hack.


> Is there an easy way to test this to see if it's what we need?

Hack a very simple test application to do some benchmarking? Apart from 
simple hard facts that we can give you on this list, evaluation is a 
matter of writing up simple code to stress test the most critical 
features that you need.

More specifically, most proper hardware should have no problem whatsoever 
with 60 µs deadlines. +/- 1 µs scheduling jitter *will* be a problem, 
though - even P-II and P-III cores with full speed cache, such as 
Celeron, P-III w/ 256 kB cache, and AFAIK, all Xeons - will have a 
scheduling jitter of few µs or more. But of course, that could be dealt 
with as well, at least in some cases;

If you get interrupts from a hardware timer, set it up to interrupt a few 
µs early, and then busy wait, polling the timer until you're at the 
correct time to start your task. (There are solutions for that in RTLinux 
as well as RTAI - at least one has a scheduler with that feature 
built-in, IIRC.)

For other interrupt sources, it's still possible to do the same thing, 
although you'll need a way to tell exactly when the interrupt occured. 
Unless the hardware has a timer with an "interrupt timestamp" latch that 
you can read, you have to rely on the system interrupt controller (and 
the ISA legacy crap won't help you there; APIC might...), or a custom 
device. You could probably add some circuitry with a timer and one latch 
for each ISA IRQ line, to timestamp any IRQs in the system (although I'm 
not sure that would give you the PCI and AGP IRQs on all chipsets), or 
perhaps a PCI device that traps the PCI IRQ lines.


//David Olofson --- Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
|      Multimedia Application Integration Architecture      |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------------> http://www.linuxdj.com/maia -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`-------------------------------------> http://olofson.net -'