Thu, 02 Nov 2000 Nathan Paul Simons wrote:
> On Thu, Nov 02, 2000 at 03:56:01PM +0200, Denis Karpov wrote:
> > i have a question. since i'm new to RTLinux and kernel programming i
> > need some safe way to experiment with stuff.
> > is it possible to run RTLinux in User Mode Linux
> > [http://user-mode-linux.sourceforge.net/]
> >
> > that means one needs to apply UMLinux and RTLinux kernel patches
> > together
> > to 'straight' kernel source. is it going to work ? did any1 try it ?
>
> Don't know about UMLinux, but you might want to try user-level signals
> in RTLinux. The actual code still runs in kernel space, but you don't have to
> know nearly as much about kernel programming to use it.
If you're going to use threads (as opposed to the ISR/callback model), you
could try user space pthreads. This is more familiar to RTL threads, and you
don't have to know *anything* about kernel hacking to get started.
As for performance, the only options that deliver reliable scheduling in the �s
range are signals to user space from some RTX (currently RTAI and RTL does
this), and of course the Real Thing; RTL, RTAI or similar (any others using
this kind of model?) RTK solution.
Next best is user space pthreads on Linux 2.2.10-lowlatency (*). This is just
a matter of using a lowlatency kernel - you run the same code, using
SCHED_FIFO or SCHED_RR, just as you would without the lowlatency patch.
Provided you don't have a crappy driver or a hardware problem, this schedules
reliably with a peak latency below 1 ms, even on low end Pentium systems.
(*) AFAIK, never versions still have problems in some areas. The latest patches
for 2.4.0-testX seem to be closing up, though.
(BTW, power management settings on the BIOS level may break RT performance on
some machines! This hits *any* OS; RTOS or not, so there's no other way than
to disable APM in the BIOS, or replace the mainboard. It might be a good idea
to disable APM in the kernel as well for lowlatency kernels, as this code may
occasionally perform lengthy BIOS calls on some machines.)
User space pthreads without the lowlatency patch would be the next lower level
of performance. The average latency of the best 90% or so schedules is the same
as for the lowlatency kernel, but the rest of the time, there will be
significantly higher latency peaks. Worst case is unknown, but several hundreds
of ms have been observed on machines with lots of non-RT work going on in the
background. (Disk access is particularly problematic.) Expect frequent
scheduling latency peaks in the 5-50 ms range, unless you throw out all
background daemons, disable swap, stay away from disks etc...
The worst solution WRT to timing is probably running *anything* under a virtual
machine or emulator. The best possible theoretical solution I can see would be
running RTL under UMLinux on a lowlatency host kernel. If this doesn't just
freeze your system, or deadlock (very likely, unless UMLinux is designed
as a *real time* virtual machine...), this could possibly run RTL threads and
ISRs with sub ms latencies. More realistically, you'll end up with performance
similar to SCHED_OTHER pthreads on a standard Linux kernel, which means
frequent delays in the tens of ms range. Not very useful if you code has any
kind of dependency on timing...
David Olofson
Programmer
Reologica Instruments AB
[EMAIL PROTECTED]
..- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
..- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> [EMAIL PROTECTED] -'
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
