*BSD News Article 3115


Return to BSD News archive

Path: sserve!manuel!munnari.oz.au!news.hawaii.edu!ames!olivea!uunet!snorkelwacker.mit.edu!bloom-picayune.mit.edu!news.mit.edu!raeburn
From: raeburn@cambridge.cygnus.com (Ken Raeburn)
Newsgroups: comp.unix.bsd
Subject: Re: 386bsd nfs hang problem -- some data, temporary workaround
Message-ID: <RAEBURN.92Aug5002605@cambridge.cygnus.com>
Date: 5 Aug 92 04:26:12 GMT
References: <RAEBURN.92Jul21181551@cambridge.cygnus.com>
Sender: news@athena.mit.edu (News system)
Organization: Cygnus Support, Cambridge MA
Lines: 30
In-Reply-To: raeburn@cambridge.cygnus.com's message of Tue, 21 Jul 1992 22:15:59 GMT
Nntp-Posting-Host: cambridge.cygnus.com

In article <RAEBURN.92Jul21181551@cambridge.cygnus.com> I wrote:

   After playing with etherfind and kernel printfs, I've come to this
   conclusion: Fragmented 8K UDP packets from the NFS server are not
   reaching the UDP layer in 386bsd....

   In the meantime, mounting NFS file systems with "rsize=1024" does get
   rid of this problem.

Acting on a suggestion mailed to me, I experimented with intermediate
sizes.  4K sometimes worked, 1K usually does, 8K simply doesn't.
Occasionally, even with 1K packets, I've gotten timeouts, though with
the smaller sizes I eventually get success.

   (It does nothing about TCP being slow, though.)

Someone suggested changing the ne2000 irq.  I changed it to use irq 5,
and the svga card jumper for irq 2 use is open, so that shouldn't be
interrupting anyways.

Outgoing traffic is fine, but incoming traffic gets about one-tenth the
throughput.  (Under 0.0 it did much better, I believe.)  Using etherfind
again, I see occasional retransmits (on the local cheapernet), and
sometimes see bursts of 20 or 30 or more packets from the PC, all with
the same seq/ack numbers, no data.

I'm not sure where to go from here, though.  Any suggestions what I
might try next, either to help with the NFS problems or to speed up
incoming TCP?  Or should I keep staring at etherfind and hope something
hits me?  :-)