tim.carlson at pnl.gov
Fri Oct 5 09:29:15 PDT 2001
On Fri, 5 Oct 2001, W Bauske wrote:
> Tim Carlson wrote:
> > I am willing to be enlightened as to how my test is flawed. I'll run
> > different tests if asked. Is my test too trivial?
> Add some other net traffic to the NIS server. Basically giving NIS
> the whole bandwidth of your network is unrealistic, at least for things
> I do. For example, if your NIS server happens to also be an NFS file
> server, also start a couple reads/writes to the NFS file systems and
> repeat your experiment and see how that effects your delays.
Then I should rename this thread.. "Re: NFS?".. or "we all know NFS sucks"
I think that is hard to design a good experiment in this case. If I
simultaneously create 120Meg files in all six nodes.. effectively taking
all the network traffic :)
foreach node (`echo compute-0-0 .... compute-0-5`)
rsh $node dd if=/dev/zero bs=1024k count=120 of=/some/file/in/nfs &
Run my previous test of executing 100 rsh's and ls'ing a directory
that requires a couple of NIS lookups, then my experiment time doubles but
finishes before any of the NFS writes have completed on the compute
nodes. The NFS writes complete in about 125 seconds so I end up with
around (7200Mb/125) 50Mb/s of NFS traffic on my 100Mb/s network. Somebody
will point out that 10Mb \neq 1MB. There is some slop in this calculation.
I think the above is a poorly designed experiment. Can you really learn
anything? All it really says is that if NFS is working as hard as it can,
you can still punch through a bunch of rsh's and do some NIS things.
FYI, syslogd is taking more CPU time on the master node
logging all of the rsh/pam data than either ypserv of nfsd.
Voice: (509) 376-0300
Email: Tim.Carlson at pnl.gov
EMSL UNIX System Support
More information about the Beowulf