Xref: utzoo comp.protocols.nfs:454 comp.sys.mips:193
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!usc!apple!mips!wje@igate
From: wje@igate (William J. Earl)
Newsgroups: comp.protocols.nfs,comp.sys.mips
Subject: Re: weird NFS speeds
Message-ID: <29033@igate.mips.COM>
Date: 6 Oct 89 21:53:47 GMT
References: <29591@watmath.waterloo.edu>
Sender: wje@mips.COM
Reply-To: wje@igate (William J. Earl)
Followup-To: comp.protocols.nfs
Organization: MIPS Computer Systems Inc.
Lines: 35
In-reply-to: gamiddleton@watmath.waterloo.edu (Guy Middleton)

In article <29591@watmath.waterloo.edu>, gamiddleton@watmath (Guy Middleton) writes:
> I have been testing NFS performance on some workstations, using a program to
> write a 20-megabyte file with different-sized buffers.  The speed listed for
> a Sparc1 when served by a Mips M/2000 is not a typo.  It really is that
> slow.  Anybody have any idea why?
> 
> write speeds, in kilobytes/sec
> 
> blocksize:		8K	4K	2K	1K
> 
> server Mips M/2000:
> 
> DECstation 3100		310	135	135
> Mips RS2030		310	140	140
> Sun Sparc1		9	108	95	145
> 
> server Sun 4/280:
> 
> DECstation 3100		79	59	53	59
> Mips RS2030		85	54	49	40
> Sun Sparc1		82	67	62	62

       You will probably have to look at the network traffic with a
"sniffer" to be certain, but the most likely explanation for the
Sparc1 client-M/2000 server case is that one or the other system
is dropping packets.  NFS performance gets terrible very fast if
someone drops packets.  If there is no other NFS traffic on either
system, look at the output of nfsstat on each.  If the client (Sparc1)
is getting rpc timeouts, then dropped packets is most likely the
problem.  If the server (M/2000) calls count goes up faster than the
client calls count, the client is probably dropping replies; otherwise,
the server is probably dropping requests.

     A sniffer would of course make the situation obvious, since you
would see just which packets were retransmitted.