Re: Fedora SMP dual core, dual AMD 64 processor system

Mark Hahn <[email protected]>
Newsgroups gmane.linux.redhat.amd64
Message-ID <Pine.LNX.4.44.0509251003440.2999-100000@coffee.psychology.mcmaster.ca>
> > sure, but so what?  so SW raid will need to transfer a few extra 
> > chunks over some of the 8GB/s HT channels, among some of the 
> > 26 GB/s of memory bandwidth available.
> 
> I didn't know Opterons could distribute the I/O operations across CPUs
> to use all that memory bandwidth.  You're throwing around theoretical
> and aggregate maximums like that's actually what you're going to get.

opterons can certainly have peripherals attached to multiple CPUs;
this is normal for nvidia-based systems, and certainly possible with
the AMD chipset.

> > why do you think that a few hundred MB/s out of many GB/s is going
> > to make a difference?
> 
> Yes, when you're moving those MBs through the CPU and turning it all
> into one huge Programmed I/O (PIO) operation.  You're not going to get

a stream of very brief block memory operations.

> GBps in transfers.  You're losing valuable chunks of time and,
> therefore, cutting cycles away from transfer time as well.

again, since the host can do the xor at several GB/s, a trickle 
of them at 250 MB/s just doesn't amount to much.

> Again, if it takes up 50% of your cycles just to push hundreds of MBs

again, 5% is about right, for an otherwise idle cpu.

> > how strange!  what on earth do you think you can do with disks
> > at 4 GB/s?  or are you worried about streaming reads from ~50
> > disks at once?
> 
> But you're not getting 4GBps.  At this point, I need to bow out of this
> discussion.  It's obvious that you believe you can push 8GB of data
> through your CPU in a second.

Stream says it only takes 3 cpus to push 8GB/s; that's triad, which
is more CPU-intense than R5.  that's also not counting write-allocate
traffic, or using prefetchnta.  similarly 4GB/s is correct, even low
for a dual.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.