Mon, 14 Aug 2000 Wilken Boie wrote:
> David,
>
> many thanks for your comment. The issue has kept me busy over the
> weekend and I found the mentioned links already. They supplied
> exactly the proper info and tools.
>
> I applied the latest matching patch I found (lowlatency-2.2.14-B1 for my
> RTAI 1.3 on Linux 2.2.14). The results are remarkable (~1-2 ms latency).
> Though unfortunately the system became unstable (X freezes and the rest
> goes mad as well after a while).
Not fun...
> So I'm wondering if anybody knows about a
>
> successfull combination of hard realtime and low latency patches
Unfortunately, I don't have much personal experience with the latest versions.
Currently, I'm running an X/KDE workstation on 2.2.10/lowlatency, which is rock
solid, and has never caused problems here. However, I have used the same kernel
at home, where it occasionally freezes if (or rather; when...) I get kicked
from the PPP/modem connection. No other problems. I haven't tried adding RTL or
RTAI to this lowlatency kernel yet.
As for later lowlatency versions, I've tried the precompiled image available at
Benno's site, and that worked perfectly on my machine at home. However, as it
isn't configured the way I like it, I tried to patch up an identical source
tree - but the kernel I built from that get very unstable when stressing the
system. Any "normal" applications (including my lowlatency audio stuff) worked
great, but Benno's latencytest (which does X stress, disk stress etc) made the
machine freeze early in the test. 100% reproducable, same spot. Haven't had
time to investigate it further yet.
> So I'm wondering if anybody knows about a
>
> successfull combination of hard realtime and low latency patches
>
> or has experience related to combining the two (I hope some of the
> people you mentioned listen).
You could perhaps post on LAD (Linux-Audio-Dev) - some of the people around
there have experience with RTL, RTAI and other solutions, and there might be
someone there who is using RTL + lowlatency on a regular basis. (I would
expect to find most RTL users on this list, but...)
Anyway, I don't think the two patches should interfere with each other on the
functional level - the lowlatency patch basically adds conditional reschedule
points in areas where the kernel can stay for too long, while RTL entirely
bypasses Linux on the IRQ level. (IFAIK, you don't even need a kernel patch to
run RTL on PPC, as that kernel has a "pluggable" HAL layer in the standard
version, as opposed to x86, which inlines STI/CLI instructions.)
> I think this could nicely cover a range of problems where hard realtime
> is too restricted (or causing too much efforts, e.g. network related)
> and soft realtime (wich just turned out to be too slow).
Actually, although you *can* do "RT unsafe" operations from within SCHED_FIFO
threads under Linux/lowlatency, that breaks the hard RT timing. As far as tests
show (*), Linux/lowlatency is very reliable as to peak latency, but of course,
the basic rules of RT programming still applies; you don't get hard RT if you
rely on *any* services that do not have bounded response time.
(*) Linux/lowlatency is way more complicated than a real RT kernel such as RTL
or RTAI, which means that it's practically impossible to specify a 100%
reliable maximum scheduling latency. For a simpler kernel, you could (at
least in theory - or at NASA) analythically specify the absolute maximum
number of cycles that any RT operation may take, but the complexity of such
an analyze explodes as the amount of code increases. The only practically
possible way to verify the reliability of Linux/lowlatency is to
stress-test machines. This has been done, and the systems we consider
working have been tested for days under high system stress without ever
missing a deadline.
As long as you're dealing with hard RT, the differences between RTL and
Linux/lowlatency are basically
lowlatency RTL
------------------------------------------------
Protected memory yes no(*1)
Security Normal(*2) None (*3)
Worst case latency <1 ms <50 �s
Use standard drivers yes no
Direct syscalls yes no
All syscalls RT safe no no
(*1) Available through RT signals
(*2) It's possible to a) have a system daemon promote normal applications to
SCHED_FIFO scheduling, so that they never need root privileges, and b)
throw in a watchdog thread that keeps these applications from freezing the
system. Root access is only required for *setting* SCHED_FIFO - not for
using it.
(*3) May not be true if the signal handlers can be in non-root programs. A
watchdog would be required just as for lowlatency, so that these handlers
cannot freeze the system indefinitely.
> I may well be wrong, but I understand that RTAIS's LXRT would suffer
> from the same problem: either I am in (restricted) hard realtime or
> encounter (unacceptable) latencies while in soft realtime.
Yeah, that's about it. One could view the different environments this way:
Hard RT environment: (RTAI, RTL, ...)
You cannot easily do anything that in non-obvious ways will make the
timing non-deterministic. RT unsafe APIs are not available for direct
use. (You *can* still reach them by sending requests off to kernel
threads or soft IRQ handlers.)
Soft RT environment: (Standard Linux, Windows, MacOS, ...)
No matter how you write your applications; there is no way to guarantee
that deadlines are not missed. Most APIs are available to all
applications, but none are RT safe. In fact, you're not even safe if
you use no APIs at all, as drivers, system services and other
applications will steal the CPU from you every now and then anyway.
"Hybrid" environment: (Linux/lowlatency, QNX, ...)
You can write hard RT application if you know what you're doing; the
kernel can guarantee that your threads will wake up within a certain
maximum amount of time [some �s on RTL and QNX, <1 ms on
Linux/lowlatency]. Most APIs are available to all applications, but
some are not RT safe; ie you can easily do undeterministic operations
from within RT code by mistake, and thus end up soft RT.
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/
