david@tasman.cc.utas.edu.au (David Nyman) (11/20/90)
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 (up to about 20 seconds for a 'pwd', for instance). 'nfsstat' will also report retransmissions and timeouts at the rate of about 30% !! This performance is not always reproducible - some NFS filesystem accesses are normal, but most suffer with the above symptoms (this is perhaps due to caching). 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. 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 ???? Hope someone can help, Dave.
jim@cs.strath.ac.uk (Jim Reid) (11/20/90)
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.
Jimlars@snus.matsc.kth.se (Lars Hoglund) (11/20/90)
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 (up to about 20 >seconds for a 'pwd', for instance). 'nfsstat' will also report >retransmissions and timeouts at the rate of about 30% !! This >performance is not always reproducible - some NFS filesystem accesses >are normal, but most suffer with the above symptoms (this is perhaps due to >caching). > >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. > I seem to remember having similiar problem with a slightly different configuration. Our problem was caused by having a DELNI (thats what DEC call it) this box is not IEEE 802.3 compliant and the SUNs did have great difficulties it was connected to the network.