Red Hat Bugzilla – Bug 128188
Very slow network I/O with kernel 2.6.7-1.492
Last modified: 2015-01-04 17:08:02 EST
When I run kernel 2.6.7-1.492 SMP on a P4 HT machine running
FC 2, disk I/O becomes very slow. "bk pull" used to take 10
minutes now takes several hours. cvs operation is also very slow.
It looks like maybe a networking issue. I will keep an eye on it.
Network performance in 2.6.7-1.492 is very bad. ssh, cvs and
bk are very slow from remote server. Another machine on the same
network running 2.4.21-15.EL is OK.
After I booted RHEL 3 U2 on the same machine where 2.6.7-1.492 + FC 2
gave me very poort network performance, my network performance went
back to normal.
Does .499 or later work better?
.503 kernel seems OK.
Saturday is my day to backup my Windows system to the Linux box, and
vice versa. I started the backup from Windows this morning. Backup
estimated that it would take 18 hours to move the 1.9GB from Windows
to Linux via Samba. Usually, the estimate is about 43 minutes.
I rebooted both boxes and got the same estimate. I then rebooted the
Linux machine from kernel 2.6.7-1.494 to kernel 2.6.6-1.435. With the
older kernel, the backup time was back to a bit more than 40 minutes.
I don't see any difference in the report from ifconfig for either kernel.
.509 kernel seems bad.
Network very slow on some web pages (e.g., CBS Market Watch) on
2.6.7-1.494. Reverting back to a 2.6.6 kernel solves the problem
Tested kernel 2.6.8 with same slow results. Running Dell D600 laptop.
Solution found under bug 126626. Need to set a couple of values under
ipv4 directory. See last post in the bug comments.
# echo 0 > /proc/sys/net/ipv4/tcp_default_win_scale
# echo 0 > /proc/sys/net/ipv4/tcp_moderate_rcvbuf
It seems that the 2.6.7 kernel changed these values from those in
2.6.6, which resulted in the slowdown. There is some suspicion that
the problem is not with the 2.6.7 kernel, but possibly with the Cisco
firewalls that may not recognize (or handle) the
tcp_default_win_scale=7 value in the 2.6.7 kernel.
the latest 2.6.9 kernels should be behaving correctly now, without editing that
sysctl. Please reopen if this isnt the case.