Tue, 16 Jan 2001 Cort Dougan wrote:
> } Actually, our practical experiences with the lowlatency patch is that you can
> } use it for hard real time as well, as long as a worst case latency of 1 ms is
> } acceptable. For multimedia (which is nearly always using buffered streaming of
> } various kinds, all the way down to the hardware level), this is excellent. All
> } we need is to make sure that buffers are processed in time. Sub 30 µs worst
> } case latency doesn't result in a significant performance improvement, not even
> } for audio.
>
> Note that this is x86. If your system requires FBCon (PPC and sparc) you
> need to learn to live with 810ms (yes, 810 milliseconds) worst-case with the
> rage128 card (similar performance for other video cards) with the linux
> low-latency patches.
That's almost impressive! ;-)
What's the fbcon driver actually doing!? And this isn't very fun on x86 either,
actually; I think using fbcon while running lowlatency threads is still on the
DDT list. Andrew Morton seems to have a solution in the works, though, if
lowlatency people really care about fbcon...
> Andrew does have FBCon listed on the "don't do this" list but that does
> rule out several systems.
I'm not sure about that; does fbcon cause trouble on PPC even when X is
running the display? (This doesn't seem to be the case with my Celeron 333
with a Permedia-2 based card running fbdev at least, but I have yet to test the
933/G400 system seriously.)
> That being said, the low-latency patches are a nice complement to RTLinux.
> RTLinux provides hard real-time and _guarantees_ while the low-latency
"Guarantee" is a rather relative term... RTL and RTAI are capable of giving
worst case guarantees in the sub 30 µs range on most systems, while lowlatency
can't do better than about 1 ms - both figures derived from real life setups,
and entirely depending on the hardware. It *might* be easier to set up a
reliable 30 µs RTL system than a reliable 1 ms lowlatency system, but I'm not
sure. Fire up a nasty X server, or enable the powermanagement of a crappy
mainboard, and both systems will start missing deadlines.
The most significant differences between RTL and lowlatency - apart from the
order of magnitude of the latency - is how complicated it is to figure out a
reliable worst case latency figure, and the latency spread. Lowlatency depends
on a lot more code, and is therefore harder to test and predict, and also has a
bigger worst case/average latency ratio than RTL or RTAI.
That said, it's not correct to dismiss Linux/lowlatency as not capable of hard
real time - unless you're going to disiss *every* real life OS running on any
hardware. Hardware can fry, the OS can crash, the OS or the hardware can case
a missed deadline, or the RT software can crash - it's just a matter of what
kind of probabilities you're dealing with, and how close to the average latency
you have to push the system.
> patches give good response for Linux processes. Most RTLinux based systems
> are built from a combination of RTLinux tasks and traditional Linux tasks,
> after all.
Yes, and even on a system on which the lowlatency patch doesn't work all the
way down to the singe ms, you still get very firm real time in user space. A
program that's tuned to miss less than a few percent of the deadlines on a
standard kernel will probably never miss a deadline even on that system, and
*never* on a fully working lowlatency system.
//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/
