Xref: utzoo comp.sys.sequent:409 comp.protocols.nfs:429
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!apple!bloom-beacon!bloom-beacon.mit.edu!jtkohl
From: jtkohl@quicksilver.MIT.EDU (John T Kohl)
Newsgroups: comp.sys.sequent,comp.protocols.nfs
Subject: Re: Problems using Sequent Symmetry as NFS server?
Message-ID: 
Date: 28 Sep 89 13:45:31 GMT
References: <3022@orion.cf.uci.edu>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: jtkohl@athena.mit.edu
Followup-To: comp.sys.sequent
Organization: /mit/jtkohl/.organization
Lines: 23
In-reply-to: iglesias@orion.cf.uci.edu's message of 27 Sep 89 19:38:20 GMT

In article <3022@orion.cf.uci.edu> iglesias@orion.cf.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.  

one thing to look at is your NFS read/write block size.  We found here
at MIT that our network router software/hardware had some problems with
the 8k packets normally used (which must be fragmented, and usually are
sent out back-to-back at maximum ethernet packet size).  Although the
network group here has finally fixed the software, Athena has for a long
time used 1k read/write packets to avoid excercising this bug.

I have seen this problem both with MIT's custom C-gateway code and with
a vendor's stock hardware/software solution with very similar topology
(lots of IP subnets on ethernet, connected to routers which sit on a
central fiber-optic campus spine).

--
John Kohl  or 
Digital Equipment Corporation/Project Athena
(The above opinions are MINE.  Don't put my words in somebody else's mouth!)