Tue, 16 Jan 2001 Nathan Paul Simons wrote:
> On Tue, Jan 16, 2001 at 10:26:36AM +0100, Bart Thissen wrote:
> > Does any body has experience with the low latency kernel patch and
> > RTL together? I did try this combination once, and found serious
> > problems under heavy load, maybe related to bad memory.
>
> Excuse me for asking, but *why* would you want to do this? If you
> have RTLinux you get hard real-time guarantees, which can be used in the same
> way low latency can.
No. You can't use Linux drivers from within RTL or RTAI without getting the same
latency problems as standard Linux user space threads. This renders RTL and
RTAI virtually useless for multimedia programming, unless you want to port all
drivers you need no actual RTL. (I was headed in that direction until the
lowlatency patch arrived, BTW.)
> As I remember, the low latency patch just sprinkled
> schedule() randomly on the kernel source like magic faery dust.
Not exactly randomly; especially not in the latest versions. They're inserted
in places where the kernel stays for "ages" occasionally, so that SCHED_FIFO
threads can be scheduled within at most 1 ms, rather than up to 100 ms later,
or worse.
Not magic and not beautiful, but it upgrades Linux from "entirely worthless"
to "totally superior" WRT serious real time multimedia.
> Shouldn't
> make a damn bit of difference to RTLinux, since it preempts the regular
> Linux kernel anytime it wants. Don't know if there are any adverse effects
> the other way around, since I haven't tried this, since I don't see the point.
Right, it shouldn't make any difference to RTL, but it makes all the difference
to code running in Linux threads - including any Linux code that RTL threads
use to interface with Linux.
An excellent example of why one might want to use both RTL and lowlatency would
be a Linux based arcade machine, game console or other serious gaming machine.
To get anything like the animation quality you see on consoles and arcade
machines, you need video refresh rate synchronization, full frame rate and
double buffering.
To guarantee full frame rate, you need to make sure that the graphics engine
gets the CPU time it needs *when* it needs it. It also needs to use various
multimedio drivers, which also need their CPU time at the right times.
Linux/lowlatency is an excellent solution for that.
Further, due to stupid design of the majority of video cards, retrace
synchronization isn't as simple as it should be. You need to poll
certain ports or registers for the "retrace bit", or similar, depending
on what video chipset you're using. The problem is that the retrace
occurs for significantly less than one ms in most resolutions, so it's
easy to miss it entirely, even with Linux/lowlatency. Besides, it's a huge
waste of CPU power, spending lots of time polling. However, RTL allows a
periodic thread to do the polling, starting just before the retrace is
expected, reducing the wasted CPU time to almost nothing. This thread can then
provide the grapics engine with a reliable retrace sync info. In the case of
graphics drivers that don't support true pageflipping, but use blits instead,
this retrace sync driver can be used to allow the back->VRAM blit to start at
the right time, which is required to avoid tearing.
//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/
