Tue, 02 Nov 1999 Basham, Richard R wrote:
> 1. Can anyone tell me what the performance benefits are for buying a machine
> with two CPUs vs. one?
It depends on what you're doing, but you can arrange the threads so that you
get less cache misses.
For periodic tasks, the jitter due to cache misses can be eliminated, but it
means you have to burn CPU time by starting early, and busy-waiting for the
real scheduling point. That's not too nice for very high scheduling
frequencies...
In general, with two CPUs, it's possible to separate the most memory intensive
tasks, so that they don't push each other out of the cache all the time. There
are patches that allow you to completely dedicate one CPU to RT processing, but
I don't know if anyone is using that method together with RTL. It would be
interesting for control rates >30 kHz. (Ultra low latency audio processing for
example. :-)
> 2. Furthermore, is there much of a hit complexity wise with getting RT-Linux
> to run on a machine with two CPUs?
Well, I did it, and had no problems - just enable Hard Real Time + SMP and
build. However, I'm not very much into SMP specific programming under RTL (yet
- I've been doing other things for a while...), so I can't say how complicated
that part of the API is to use.
> 3. Are there any interface card issues I need to know about?
You mean if there are drivers, or if there can be SMP problems?
Don't know of any SMP specific problems here, but I know of one problem; the
lack of drivers for various standard hardware. I'm working on a Driver
Programming Interface, but haven't had much time for it lately... It currently
allows ported chrdev drivers to be used from RTL and standard Linux - at the
same time, if they support multiopen or have multiple functions (ie soundcards;
the main reason why I started hacking the DPI).
The idea is to provide wrapper header files that let you port drivers by doing
little more than using the wrapper headers and changing any code that pokes
directly in kernel structures. (The kernel API is getting more and more macros
for frequently used operations, so there won't be much work left to do in newer
drivers.)
(See sig for site URL - chech the downloads section.)
> 4. Are there any issues with using PIII over PII?
Don't know much about P-III vs P-II, but I do know that Celeron outperforms
all other (AFAIK - not sure about Xeon) Intel CPUs. That goes for the late
lowlatency patches (ms precision hard real time in user space SCHED_FIFO
threads) as well - my Celeron 333 has less than half the jitter of a similar
P-II system. I haven't really pushed that machine with RTL, but I have done
audio streaming (card in -> thread -> card out) with 9 samples (44.1 kHz) delay
using 8 samples DMA buffers. That is, one sample period to cover the scheduling
jitter + the overhead of the while(1) {read(); write();} in the thread and
driver... Rock solid, regardless of system stress.
(
If you're interested, you can get the lowlatency patch from
http://www.gardena.net/benno/linux/audio/
and there's a mini-HOWTO on
http://www.replicant.apana.org.au/~jlittler/lowlatency.html
)
//David
·A·U·D·I·A·L·I·T·Y· P r o f e s s i o n a l L i n u x A u d i o
· ··---------------------------+-----------------------------------·· ·
·Rock Solid ·Low Latency | - David Olofson - ·Audio hacker
·Plug-Ins ·Open Source : ·Linux advocate
www.angelfire.com/or/audiality · [EMAIL PROTECTED] ·Singer/composer
--- [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/
