Bug 64123 - NFS / TCP mounted filesystems perform REALLY bad with eepro100 driver.
Summary: NFS / TCP mounted filesystems perform REALLY bad with eepro100 driver.
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.1
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Pete Zaitcev
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-04-26 00:25 UTC by Mike Cooling
Modified: 2007-04-18 16:42 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2002-04-26 15:07:31 UTC
Embargoed:


Attachments (Terms of Use)

Description Mike Cooling 2002-04-26 00:25:53 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.79 [en] (Win98; U)

Description of problem:
In trying to debug problems described in bug #58747 Network Appliance asked us to try a NFS-TCP mount instead of using the default NFS-UDP. 
Filesystem access performed so poorly we had to go back to UDP. Further testing and enet sniffing showed when mounted with TCP and doing a 
cat of a very large file to the screen the data flow would hang for seconds and flow to the screen would be very bursty. Sniffer showed transfer rate 
on the 100Meg network was 50-200 packets per second. However (in the sniffer file) we can't see why packet flow is so slow.

Remounting the filesystem with NFS TCP and doing the same test showed a much smoother flow and a packet rate of 1300-1450 packets per 
second. Both above tests were using an Intel 82557 enet card with the eepro100 driver.

We also have a 3-com 3c980 enet card installed as eth2 using the 3c59x driver. When enabling NFS TCP and doing this same test it performed 
just as the UDP test above with a very smooth data flow to the screen.

Sniffer file available on request.


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Using the above ethernet card and driver, mount an NFS filesystem with TCP and 8k rsize/wsize.
2. Find a huge text file and cat it to the terminal.
3. Observe the results.
	

Actual Results:  Output to screen very bursty with 1-4 second pauses before output flow continues.

Expected Results:  Output should flow to screen continuously without interruption.


Additional info:

Test performed on an IBM Netfinity x330 Server Type 8654 Model 51Y. System has dual Pentium 3 processors.

Besides this test we tried running an actual application using the nfs-tcp mount. The application uses Apache and usually starts within 1 second, 
spawning about 6 processes. When using the tcp mount the application took about 90 seconds to start and was completely unusable. Just doing 
an ls of files on the file system with application running took 30-60 seconds.

Comment 1 Pete Zaitcev 2002-09-10 22:18:22 UTC
Folded back to 58747 as far as I can tell...



Note You need to log in before you can comment on or make changes to this bug.