} 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.
Andrew does have FBCon listed on the "don't do this" list but that does
rule out several systems.
That being said, the low-latency patches are a nice complement to RTLinux.
RTLinux provides hard real-time and _guarantees_ while the low-latency
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.
-- [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/
