[CentOS] Ethernet poor performance

[Robert Moskowitz]

nate wrote:
> 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: [50] 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
> 'lsmod'
>
>
>   
>>> - 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
> changes.
>   
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:208.83.67.132 Bcast:208.83.67.135 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 
experiences.