Red Hat Bugzilla – Bug 176424
network lag on startup with tg3 driver
Last modified: 2007-11-30 17:11:19 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Description of problem:
When the machine first boots up it has very poor network performance. Using the actual terminal performs fine however if I use any network application it does not respond quickly and feels laggie. This clears after about 10 minutes.
The machine is an HP Proliant ML350 and uses the tg3 driver for its network card.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install FC4 and latest fedora kernel on a HP Proliant ML350
2. reboot the machine
3. Try to use a network application with the server once it has completed booting
Actual Results: When I am ssh'ing into this machine (over a 100Mbit network) I sometimes have to wait 5 - 10 seconds for my key strokes to appear. If I am scp'ing files to or from it I get transfer speeds in the 10 - 15k/s range.
I multicast stream live TV from this machine and if I set the system to start on boot I get tons of sequential errors and a distorted picture.
If I leave the machine for 10 minutes or so it clears up fine and then performs great.
Expected Results: Decent network performance, text should appear as I type with ssh, clear pictures and no sequential errors when streaming TV, decent scp speeds for a 100Mbit network.
I have encountered the problem in the following kernels.
2.6.14 on FC3 (custom) and FC4 (fedora release)
2.6.12 on FC3
However I do not get this problem on FC3 running the 2.6.9 kernel.
Forgot to add this...
According to lspci the network card is...
01:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5705_2 Gigabit
Ethernet (rev 03)
I get no error messages in /var/log/messages whilst I'm getting bad network
It's difficult for me to imagine what would cause the behaviour described
above. Can you give me some idea of what your network looks like between the
video client and the video server?
What protocols are in use for your video streaming?
If you stop the video stream and let the client "cool off" for a while, do you
get similar behaviour when restarting? Or is this truly only at boot?
Would you mind attaching that output of running "sysreport" on the video
Created attachment 122957 [details]
sysreport for video server
The server connects directly to an Allied Telesyn AT-8724XL switch and my
Windows PC also connects directly into that switch. We do a lot of work with
streaming TV and Video but have only recently updated from kernel 2.6.11 to
2.6.14 (and thus FC4). This problem occurs if we have no-one else on the
network or if we have a couple of servers streaming video.
We are using VLC (0.8.4) to stream the TV from the linux server and I'm also
using VLC on my windows client to view it. We are using just plain UDP
streaming to multicast addresses.
I'm not sure if I described it very well but the problem doesn't only just
occur when I'm streaming video. Even if I don't have the streaming tv starting
on bootup I get very poor response via ssh or http, its just really noticable
with streaming video. So network usage should be really low if I'm just ssh'ing
As I'm not running linux on the "video client" I cannot run sysreport however I
have attached the sysreport for the video server.
This is a mass-update to all currently open kernel bugs.
A new kernel update has been released (Version: 2.6.15-1.1830_FC4)
based upon a new upstream kernel release.
Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.
This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.
Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.
If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.
Closed due to lack of response...please reopen when the bug is verified
against current kernels...thanks!