Bug 67461 - poor nfs performance with kernel 2.4.18-5
Summary: poor nfs performance with kernel 2.4.18-5
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.3
Hardware: athlon
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
URL:
Whiteboard:
: 67199 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-06-25 17:03 UTC by Steffen Griebel
Modified: 2014-01-21 22:48 UTC (History)
8 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2004-09-30 15:39:42 UTC
Embargoed:


Attachments (Terms of Use)
nfs startup script (2.85 KB, text/plain)
2002-06-25 21:13 UTC, Steffen Griebel
no flags Details

Description Steffen Griebel 2002-06-25 17:03:05 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.0.0-10)

Description of problem:
I have upgraded my two systems to the new kernel. System A ist an Intel Pentium2 450 MHz System, System B ist an AMD 1000 Mhz. Both system are connected via 100 Mb network. With kernel 2.4.18-4 on both sides nfs is working fine. After upgrading I have a read perfomance of about 30 kbit/s. 
If I use the old kernel on the athlon machine the performance is good again.

With tcpdump I see many icmp messages: "ip reassembly time exceeded tos 0xc0"

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


How reproducible:
Always

Steps to Reproduce:
1. running kernel 2.4.18-5 on Intel
2. running kernel 4.4.18-5 on AMD
3. using NFS
 

Actual Results:  slow nfs performance

Expected Results:  normal nfs performance

Additional info:

Comment 1 Ben LaHaise 2002-06-25 19:41:34 UTC
Which network cards and drivers are being used between the systems?  What is the
configuration of the nfs server?

Comment 2 Steffen Griebel 2002-06-25 21:13:43 UTC
Created attachment 62604 [details]
nfs startup script

Comment 3 Steffen Griebel 2002-06-25 21:20:35 UTC
 Ok, on both servers are 3Com PCI 3c905B Cyclone 100baseTx installed, using the default 
driver 3c59x comming with the kernel. Configured with option=8 in /etc/modules.conf. With 
these settings I get a 100 Mbit/s full-duplex connection. I have also checked 
/var/log/messages to see that it's really a full-duplex connection.  
 
I haven't changed any settings for the nfs-server. But nevertheless I have attached the 
nfs-startup script to be sure.

Comment 4 Steffen Griebel 2002-06-25 21:48:03 UTC
I have done some more tests and have seen that it's not only a problem with nfs, even ftp 
is really slow independet of the network card configuration - I have tried option=5 
(100base-FX) on both sides - nothing changed. With SFTP I will get a transfer rate of 
about 300-400 kbit/sec without any icmp messages and without errors on the eth0 
interfaces.

Comment 5 Ben LaHaise 2002-06-25 21:56:00 UTC
What network drivers are involved?

Comment 6 Steffen Griebel 2002-06-25 22:02:44 UTC
Sorry, I don't understand your question. I'm using the default kernel driver 3c59x.o. 
Maybe this helps: 
 
3c59x: Donald Becker and others. www.scyld.com/network/vortex.html 
See Documentation/networking/vortex.txt 
00:0b.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x9800. Vers LK1.1.17 
 00:04:76:73:3b:d7, IRQ 10 
  product code 4d4c rev 00.12 date 07-26-01 
  Internal config register is 1000000, transceivers 0xa. 
  8K byte-wide RAM 5:3 Rx:Tx split, autoselect/10baseT interface. 
00:0b.0:  Media override to transceiver type 5 (100baseFX). 
  MII transceiver found at address 24, status 784d. 
  Enabling bus-master transmits and whole-frame receives. 
00:0b.0: scatter/gather enabled. h/w checksums enabled 
eth0: Media override to transceiver 5 (100baseFX). 
eth0: Initial media type 100baseFX. 
eth0: vortex_up() InternalConfig 01500000. 
eth0: vortex_up() irq 10 media status 8080. 


Comment 7 Steffen Griebel 2002-06-25 22:06:12 UTC
These servers are connected with an switch from `level one`. Or, also tested, directly 
with an crossover cable. Is it that what you've ment?

Comment 8 Arjan van de Ven 2002-06-26 00:03:38 UTC
Could you try the 2.4.18-5a kernel at

http://people.redhat.com/arjanv/testkernels/

it has a 3c59x bugfix...

Comment 9 Arjan van de Ven 2002-06-26 00:03:40 UTC
Could you try the 2.4.18-5a kernel at

http://people.redhat.com/arjanv/testkernels/

it has a 3c59x bugfix...

Comment 10 Wolfgang Ocker 2002-06-26 07:21:30 UTC
Here my success report for -5a:

After I upgraded my LTSP server to -5, the X connections became slow and
jerkily. The network card used on the server is a 3c905B. Everything works fine
with -5a.

Comment 11 Steffen Griebel 2002-06-26 16:12:57 UTC
If have installed the -5a kernel on both machines, but nothing changed. There are still 
the performance problems and I still see the icmp-messages.

Comment 12 Rex Dieter 2002-06-27 14:11:47 UTC
See also my bug #67199 "kernel-2.4.18-5, very slow nfs(w/sync) ~50k writes".

Comment 13 Chuck Lever 2002-07-26 00:07:24 UTC
Steffen-

The NFS problem may be the result of a known problem with the IP fragmentation
logic in the IP layer.  From your description, you are probably using NFS over
UDP.

Try increasing the transport socket buffer size:
1.  Log onto your client as root
2.  cd /proc/sys/net/core
3.  echo 262143 > rmem_max
4.  echo 262143 > wmem_max
5.  echo 262143 > rmem_default
6.  echo 262143 > wmem_default
7.  Remount your NFS file systems on the client
 
Another option is to try mounting explicitly with NFS over TCP.
 
Actually, this hints at the real cause, which may be network problems causing
severe packet losses.

Comment 14 Rex Dieter 2002-08-07 16:48:16 UTC
*** Bug 67199 has been marked as a duplicate of this bug. ***

Comment 15 Rex Dieter 2002-08-16 17:43:41 UTC
FYI, the 2.4.18-7 test kernels work great!  NFS speeds are respectable, even 
when exported/mounted 'sync'.

Comment 16 Bugzilla owner 2004-09-30 15:39:42 UTC
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/



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