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? :-)