<<<
PLS excuse, if this mail appears again. But on my account it didn't
show up within two days. So I'm afraid it did not get thru.
>>>
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).
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).
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).
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.
Wilken
> Wilken Boie wrote:
> > ...
> > I tried to follow the advice given many times: trigger a user space
> > helper (I'm using /dev/rtf0). My helper thread blocks on reading
> > a byte written by a RTAI module ervery 20ms and then sends some data.
> >
> > My aim is to send a udp broadcast as closely bound to that trigger as
> > possible. Jitter would be well acceptable up to 1+ ms. I assumed to
> > achieve that by setting the helper thread to SCHED_RR with a high
> > priority (e.g. 99).
> >
> > But I find this construct working quite precise only most of the time:
> >...
>
David Olofson wrote:
>
> Indeed, this is to be expected from the soft real time scheduling provided
> by SCHED_RR or SCHED_FIFO. (BTW, you should usually use SCHED_FIFO for this
> kind of stuff, unless you have multiple RT threads that will use lots of CPU
> time.) As opposed to RTL, it's not *hard* real time.
>
> However, it is possible to get worst case latencies in the ms range with Ingo
> Molnar's lowlatency patch. I think some people have succeded in applying
> some versions of lowlatency and RTL together, which allows the great
> combination of kernel drivers with µs timing and user space code with ms
> timing. Have a look at:
>
> http://www.gardena.net/benno/linux/audio/
>
> http://www.crosswinds.net/~linuxmusic/lowlatency.html
>
> Another alternative (which should provide significantly lower latencies) would
> be the new hard RT signals from RTL. (Still beta, AFAIK.) I believe RTAI has
> had a similar feature for some time.
-- [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/
