Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!gatech!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!strath-cs!baird!jim
From: jim@cs.strath.ac.uk (Jim Reid)
Newsgroups: comp.protocols.nfs
Subject: Re: NFS performance on Sun/VAX network
Message-ID: <JIM.90Nov20122239@baird.cs.strath.ac.uk>
Date: 20 Nov 90 12:22:39 GMT
References: <1865@diemen.utas.edu.au>
Sender: jim@cs.strath.ac.uk
Followup-To: comp.protocols.nfs
Organization: Computer Science Dept., Strathclyde Univ., Glasgow, Scotland.
Lines: 50
In-reply-to: david@tasman.cc.utas.edu.au's message of 20 Nov 90 00:50:39 GMT

In article <1865@diemen.utas.edu.au> david@tasman.cc.utas.edu.au (David Nyman) writes:

   I am having problems with NFS performance on our network.  Our network
   consists of:

   1. Two Sun 4/330's, 
   2. One VAX 6310 with 13 DEC terminal servers, and 
   3. One Vista terminal server, supporting 16 terminals for either LAT or
   TCP/IP connections.

   If I NFS mount a filesystem from the Sun NFS server on the Sun NFS client,
   access to the NFS filesystem on the client is abysmally slow

   I have attempted isolating the Sun/4's from the network, and, hey presto,
   the problem goes away !!  No 'nfsstat' errors, timely responses, and all is
   rosy.  Reconnecting to the network brings the problem back.

   Has anyone had similar problems?  I firstly wondered if the VAX was
   swamping the network, even though it is only servicing the terminal
   servers.  I find this hard to believe, but I'm open to any suggestions.

Check all your network connections. You may have a loose transceiver
or something degrading the network. NFS stresses an ethernet because
NFS hosts can generate lots of traffic: two Suns can happily guzzle most
of an ethernet's bandwidth with normal NFS client and server exchanges.

If something is dropping packets or intermittently shorting the cable, NFS
packets are more likely to be lost since there will probably be more of
them than anything else on your network.

Is netstat reporting lots of bad packets, collisions or dropped
packets? Run etherfind on a Sun and have a look at what traffic is
going through your ethernet. That'll tell you if the VAX and terminal
concentrator are to blame.

It's unlikely that your VAX or terminal server can generate enough
traffic to upset NFS between the Suns. It is possible though.

   It's also important to note that other network services (telnet, rlogin,
   rcp, etc) do not suffer from any degradation in performance.  This is only
   a subjective comment, but if there is a problem with the other services it
   is nowhere as apparent as with NFS.  Also, the nfs daemons on the NFS
   server do not accumulate CPU time ????

This is because NFS is less able to deal with dropped requests as it
uses UDP (a datagram protocol) for requests and replies. Rcp and the
like use TCP which is better able to adapt to the prevailing
conditions on the network. Also, the timescale for noticeable delays
in round trip times for a telnet session (say ~0.5 second) is much
more than for an NFS request - typically 10 or 20 milliseconds.

		Jim