Xref: utzoo comp.sys.sequent:410 comp.protocols.nfs:431
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!uunet!mcsun!unido!fauern!immd4.informatik.uni-erlangen.de!eckert
From: eckert@immd4.informatik.uni-erlangen.de (Toerless Eckert)
Newsgroups: comp.sys.sequent,comp.protocols.nfs
Subject: Re: Problems using Sequent Symmetry as NFS server?
Message-ID: <508@medusa.informatik.uni-erlangen.de>
Date: 28 Sep 89 12:25:38 GMT
References: <85680@pyramid.pyramid.com>
Organization: IMMD IV, University of Erlangen, W-Germany
Lines: 46

From article <85680@pyramid.pyramid.com>, by csg@pyramid.pyramid.com (Carl S. Gutekunst):
> In article <3022@orion.cf.uci.edu> iglesias@orion.oac.uci.edu (Mike Iglesias) writes:
>>On occasion (more often than we'd like), the client systems will start
>>printing messages about the NFS server not responding.  This goes on
>>for about 45 seconds or so, and then the client can talk to the server
>>again.  We don't see this on Suns that are on the same subnet as the
>>Sequent server, which could indicate it's a network problem.
> 
> That's the key that tells you it's a routing problem. You can easily verify
> this by attempting an rlogin at the same time as NFS is having trouble. If
> the rlogin just sits there, then routing is the problem.

I don't think that the problem is a routing problem, given that
no other machines experience this. Also, if the udp packets from
the NFS client cannot find their way to the NFS server, the
error message is usually>

"NFS  failed for server : RPC: Unable to send".

whereas the error message for a non responding NFS server that is
reachable through the network is usually:

"NFS server  not responding, [still trying]"

This was the error that Mike Iglesias described. We are experiencing
the same problems with our S81, and the clients are on a directly
connected network! We have traced this for long, and in fact,
our Sequent is loosing packets.

This problem has been acknowledged by sequent, they say that it
is a hardware problem on the ethernet interface on the SCED.

One remarkable effect is that the sequent stops serving any NFS request
for 30 to 45 seconds from time to time. This follows directly
from the packet losses of the ethernet interface.
The overall effect is that we cannot get the expected NFS performance
from the sequent (we are using it as a NFS server for both swapping
and usual Filesystem access for several SUN clients).

Help ? I don't know by now, maybe we will try to use the VME-bus based
ethernet controller.


Toerless Eckert X.400: 
		RFC822: eckert@informatik.uni-erlangen.de
		UUCP:   {pyramid,unido}!fauern!eckert BITNET: tte@derrze0