Mon, 15 Jan 2001 Alexander Lichius wrote:
> Hi David,
>
> Monday, January 15, 2001, 11:52:11 AM, you wrote:
>
> >> DY> I am booting with RTLinux-2.0. The reason why I do this high frequency
> >> DY> (1000 Hz) task in linux instead of RTLinux is because this task need to
> >> DY> use lots of graphics, big memory (60M) for object modeling, etc which are
> >> DY> cubersome to do in RTLinux.
> >> if you could do it, i will change my religion at once .... ;)
>
> DO> I don't knaw about religion, but I've been running SCHED_FIFO threads at 1 kHz
> DO> and beyond without problems on machines like Celeron 333 and P-II 400. (Any
> DO> decent socket 7 generation Pentium system does rather well too.)
>
> i tried to express that running a rtlinux task with the above
> mentioned requirements (graphics, 60M+ memory usage) directly in the
> rtlinux kernel without any user-app would seem godlike to me ... for
> that i would change my religion ... ;)
Ah, I see! :-)
That's basically the same reason why I'm not using RTLinux or RTAI for my audio
processing any more. (Might port some drivers when I have some serious
production code to use them with, though. The discouraging thing is that the
average sound card has several times higher latency in the digital filters than
an RTL based audio engine would have from input to output...)
> besides, thank you for your hint on the scheduling latency issue (i
> didn't expect such a response - more then 15 mails - wow ;*) ). if i
Well, that's just the way we are around here - all low latency addicts! ;-)
> have some time available i will do some stress tests and will inform
> you again. i am going to play around with some BIOS settings as well,
> as i assume that some hardware may cause those high latencies.
Yep. The first things to try are probably power management (causes problems on
some main boards), and the PCI retry settings. (Bus master DMA may be allowed
to block the bus for longer periods of time than what's acceptable when running
a real RTOS.)
> does anybody has some hints regarding cache and harddisk
> configuration (i have to dig into hdparm and stuff right now)?
Disabling the (CPU!) cache will decrease the jitter (at the expense of average
latency, AFAIK), but it will also slow down the CPU to a crawl. However, as
it's only a matter of a few �s, it's probably not of much interest, unless you
can really accept using a monster overkill PC to do the job of a medium powered
DSP. (For prototyping and very small series, that could actually be viable, as
it can cut development costs a great deal.)
As to the hard drives, enabling DMA is pretty much essential for good
performance with the lowlatency patch (as the user space RT threads cannot
preempt lengthy memory copy operations in kernel space), but shouldn't matter
much to RTL, RTAI and similar solutions. In the latter cases, the RT threads
preempt *everything* - except the hardware!
That is, enabling DMA *could* potentially make things worse, if the controller
is nasty and the chipset allows it to hog the PCI for too long, or if the
driver cheats with some command FIFO or similar hardware interface. Don't know
if anyone has actually seen that, though. (It would basically be the same
problem that has been observed on video cards, and could theoretically be
caused by any PCI or AGP card that does heavy busmaster DMA, or uses a command
FIFO with h/w blocking or similar.)
//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/
