Tue, 16 Jan 2001 [EMAIL PROTECTED] wrote:
> On Tue, Jan 16, 2001 at 08:17:00AM -0700, John Regehr wrote:
> > The point is that real-time applications have widely varying
> > requirements and, as people have been discussing recently, not everybody
> > wants to stuff their app into the more restricted and difficult
> > enviroment.
>
> I want to point out that (A) RTLinux programming environment is not so
> difficult and (B) the low latency patches are not so unrestricted.
> Andrew Morton (who seems to have been the second Linux developer to turn
> into an entire programming team) has a list of "don't do that"'s to
> accompany his patch.
Indeed, some versions of the patch are not even practically usable for real
applications. However, the DDT lists were mainly a "lowlatency on 2.3.4"
storry, and were the result of cutting the patch down to a level of ugliness
that Linus would accept in the mainstream kernel.
Also, that was before some plain bad code was fixed. This code had impact on
performance and SMP in particular, as well as on worst case latencies, and
these fixed, the DDT list will be more or less eliminated, while still alowing
a minimal number of "ugly" conditional reschedule points to guarantee excellent
performance under all kinds of system stress.
BTW, looking at the latest lowlatency versions for the latest 2.4 kernels, it
seems that Linux 2.4 is approaching a level where the lowlatency patch won't
even be needed. (Thanks to the work related to SMP performance, mostly.)
According to another post I read somewhere, Mingo's *real* lowlatency patch
ported to 2.4 keeps the worst case latency on some of the test systems below
0.35 ms, IIRC. Almost 3 times better than the original lowlatency patch on
2.2.10, that is. :-)
> > One drawback of running soft real-time apps in user space while running
> > hard real-time apps in RTLinux is that RTLinux will become a source of
> > latency for regular Linux. In other words, if a RTLinux task has a WCET
> > of 1ms, then the worst-cast dispatch latency of regular Linux will be
> > increased by 1ms.
>
> Just as the worst-case dispatch latency of SCHED_OTHER processes in
> Linux gets worse by the worst case compute time of and SCHED_FIFO process.
The same goes for RT threads running under the same scheduler in any
environment, unless some kind of high frequency time sharing is used. Lower
priority threads always depend on the higher prio threads not to increase their
worst case scheduling latency too much. (See why multiuser systems generally
don't provide real time scheduling for all users?)
//David
..- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------> http://www.linuxaudiodev.com/maia -'
..- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`--------------------------------------> [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/
