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!)