[CentOS] Ethernet poor performance
rgm at htt-consult.com
Wed Jul 2 17:43:14 UTC 2008
> Robert Moskowitz wrote:
>> Intel the first time, DLink (Realtek) currently. Both 10/100Mb
> There's a lot of different Realtek chips out there, can you
> send the output of lspci -v (and capture the network card only since
> it spits out a lot of output). I've heard lots of bad things over
> the years about Realtek cards though my personal experience with
> them has been fine(last one I used I bought probably 6 years ago).
00:0e.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
Subsystem: D-Link System Inc Unknown device 1301
Flags: bus master, medium devsel, latency 66, IRQ 10
I/O ports at 1000 [size=256]
Memory at 40000000 (32-bit, non-prefetchable) [size=256]
Capabilities:  Power Management version 2
See my prior post for mseg info on this card.
>>> - What driver is it using?
>> How do I tell?
> Check in /etc/modprobe.conf, also you can include the output of
>>> - Can you verify that the speed and duplex settings match on both ends of
>>> the connection?
>> The switch has its 100Mb LED on. One of the switch ports has my
>> Speedstream router which is only 10Mb, so we can believe the 100Mb LED.
>> This is a dumb switch (my public network, so I am not going to plug into
>> one of my Procurves).
> Since it's a dumb switch there's probably no way to confirm duplex settings.
> One thing you could try is hard setting the NIC to the various different
> options and see if things improve. It could be that auto negotiation is
> failing so they are running at mismatched duplexes. Which depending on
> the quality of the switch will depend on the results. About 10 years ago
> I had a 3COM network card and a Linksys switch that just refused to
> co-operate. Of course 3COM blamed Linksys and Linksys blamed 3COM. Ended
> up going with a netgear switch and that 'fixed' it.
> You should be able to use the 'ethtool' command to force duplex/speed
I will change addresses on this card and plug it into one of my Procurve
switches. That will tell me part of what is going on.
>> No and no.
>> eth1 Link encap:Ethernet HWaddr 00:50:BA:42:82:49
>> inet addr:188.8.131.52 Bcast:184.108.40.206 Mask:255.255.255.248
>> inet6 addr: fe80::250:baff:fe42:8249/64 Scope:Link
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:1709 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:1033 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:535351 (522.8 KiB) TX bytes:117321 (114.5 KiB)
>> Interrupt:10 Base address:0xa000
> Quite unusual..
>> ho, ho. MTU of 1500. Is this not doing MTU path discovery? But these are
>> little PINGs so there should not be any frag problems (my WAN link is
>> PPPoE, so you want pathMTU or have to hard config everything to
>> 1415bytes per the pppoe man pages).
> The only experience I have with MTU discovery is with jumbo frames, and
> as far as I know MTU discovery is only available for TCP, not UDP or
> ICMP. You could certainly manually set your MTU to 1415 with
> ifconfig eth1 mtu 1415, but as you say the packets your sending are
> tiny anyways so it probably won't have any impact.
>>> - Try replacing the card itself? maybe it is bad.
>> On my 2nd card already.
> Of the same type? Try another brand/model? Get another Intel card,
> or a broadcom-based card(3COM or something).
Different types. I have to use what I have sitting around for right now.
> I wouldn't expect IRQ conflicts to be much of an issue with this type
> of problem, such tiny amounts of traffic on the card. I can't even
> remember the last time I had to deal with IRQs, 4-5-6 years? Things
> seem to work pretty well these days.
Same here, but when you are groping for answers, you fall back on old
More information about the CentOS