list is alive (fwd)
Many of your questions may have already been answered in earlier discussions or in the FAQ. The search results page will indicate current discussions as well as past list serves, articles, and papers.
Robert G. Brown rgb at phy.duke.eduFri Jul 27 12:09:34 PDT 2001
- Previous message: list is alive (fwd)
- Next message: ld -r and mpprun
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: list is alive (fwd)
- Next message: ld -r and mpprun
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Beowulf mailing list
