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.