How to *use* multiple GigE adapters into a single PC
bdavids1 at gmu.edu
bdavids1 at gmu.edu
Mon Jul 22 07:25:01 GMT 2002
ServerWorks Grand Champion HE chipset supports dual Pentium 4
processors. There's 3.2 GB/s to each proc, and with quad-interleaved
DDR memory, you've got a 6.4 GB/s memory bandwidth.
Compaq's DL530 and ML580 seem to fit what you're looking for. They
have 4 100MHz 64bit PCI-X busses. The ML580 has 7 64-bit PCI-X slots.
For a single processor system, I think the FSB becomes the bottleneck,
at 3.2 GB/s (that's GigaBit, right?). So that would be 400
MegaBytes/sec. (4) 117 MegaByte/sec connections would be 468 MByte/sec.
How does DMA fit into all of this? Can data be written/read to/from
disk into a buffer via DMA, and thus not eat up FSB bandwidth? Same
question for the networking. I know, that's more a question of what
the drivers do - I'm just writing down some of the questions going on
in the back of my head...
Ok, so the disk system really would be the bottleneck, unless you had a
really big RAM drive or most of the file requests were for data already
in cache. For testing that shouldn't be a problem.
http://www.serverworks.com/products/GCHE.html
Brian Davidson
George Mason University
----- Original Message -----
From: Richard Sharpe <rsharpe at ns.aus.com>
> Hi,
>
> On Friday I managed to get a single PC to suck down something like
> 117MB/s
> from a NetApp F840 using cifs-load-gen.
>
> The only PC-like platforms that I can think of that would be able
> to
> [ab]use all the bandwidth available in two or more GigE adapters
> would be
> things like the AMD 760MPX-based mobos or some Intel mobos with
> multiple
> 64-bit 66MHz PCI slots. Can anyone point to any others?
>
> I know that Intel provide dual GigE channels on one card, so this
> would be
> a way to put four into one PC, but I am not sure you would have
> much
> memory bandwidth left over.
>
> I want to find a way to test the multi=interface stuff I want to
> put into
> cifs-load-gen and find where its limits are from a load-generation
> point
> of view.
More information about the samba-technical
mailing list