list is alive (fwd)

Robert G. Brown rgb at phy.duke.edu
Fri Jul 27 12:09:34 PDT 2001


On Thu, 19 Jul 2001, Eugene Leitl wrote:

>
> Btw Robert, do you have to add anything to your FS108 short report?
> 	http://www.beowulf.org/listarchives/beowulf/1999/08/0163.html
>
> I've just bought an FS108 for my fledgling home 'wulf, and would like to
> benchmark how well my two Tulips (one old original Netgear, and the other
> one a newfangled Intel derivate).
>
> What is the easiest way to tell when I'm running into problems, netperf?
> If yes, what are the options to use?
>
> TIA,
> Eugene

Sorry for the late response, but even I go on vacation sometimes (hasn't
it been quiet on the list lately;-).

I don't have much to add, except that I've gotten a matching 16 port
switch to support our home remodelling (which includes two twelve port
RJ45 punchblocks, numerous "workstation locations", and a dedicated
cluster of 8 RJ45 sockets).  I haven't taken it out of the box yet, but
it only cost a bit more than the FS108 did when I got it.

As far as benchmarking performance is concerned, I currently use or have
used a mix of netpipe, netperf (which has unfortunately been pretty much
frozen and no longer seems to be maintained) and the microbenchmarks in
lmbench (some of which were added or modified at my request).

The key thing is to separately measure latency (generally derived from
bandwidth in the small packet regime) and "bandwidth" (generally held to
be a peak value for appropriately sized packets).  I really prefer to
sweep a series of measurements (for any tool that supports it) for all
possible message lengths from 1 out to whatever fills at least one MTU.
This can sometimes reveal unexpected and interesting structure as the
kernel, the memory subsystem, the caching subsystem, and the card's
driver all interact.  I've even found it possible to crash particular
kernel/driver revisions in years past with certain streams of input
packets.

My recollection of the FS108 was that its latency was unexciting but
that one could achieve "decent" bandwidth through it, suitable for a
home beowulf or a not-too-demanding parallel task.  I expect that my 16
port switch will do the same.  This is at least partly a mixed function
of the network cards being used as well.  It is a decent idea to connect
the two hosts in question with a crossover cable (no switch at all) to
get a baseline result for the cards alone and then redo the sweep(s)
with the switch in place.

I do have some perl scripts for sweeping e.g. netperf or btcp across
various packet sizes, and netpipe does its own sweep of sorts by
default.

   rgb

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu







More information about the Beowulf mailing list