0

I recently attempted to transfer a 3 GB file to a machine on my LAN using rsync -azvP. I noticed I was only getting 50kpbs. Both switch ports are 100/full. When I do an ifconfig, here's what I get:

eth0      Link encap:Ethernet  HWaddr 00:30:48:2E:A3:78  
          inet addr:172.16.0.1  Bcast:172.16.0.255  Mask:255.255.255.0
          inet6 addr: fe80::230:48ff:fe2e:a378/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:747209956 errors:0 dropped:0 overruns:0 frame:0
          TX packets:864422049 errors:16806813 dropped:0 overruns:0 carrier:16806813
          collisions:20239785 txqueuelen:1000 
          RX bytes:793010164 (756.2 MiB)  TX bytes:2059589267 (1.9 GiB)
          Base address:0x4000 Memory:da400000-da420000

I noticed: TX packets:864422049 errors:16806813 and collisions:20239785

Looks like I'm getting errors and collisions. Is there something obvious that I'm missing? My next step is to change the cable. What if that is unsuccessful?

Improve this question
1
  • 1
    Replace HUBs in your network with switches :))))
    – kolypto
    Oct 29, 2009 at 0:44

5 Answers 5

Reset to default
6

Replace the cable, then change ports, then the switch, then the sending NIC, then the receiving NIC, then the sending motherboard, then the receiving motherboard.

Improve this answer
4
  • I'm hoping for a configuration fix before I go for the OSI model. :-)
    – randomx
    Oct 27, 2009 at 12:32
  • 1
    @randy: My experience has been that troubleshooting often starts at the lower layers and works up, rather than the other way around. "Is it plugged in?" "Is it a good cable?" "Is it a good NIC / port?" are all pretty easy questions to answer and can end up being the solution to problems that, otherwise, often manifest themselves as various odd behaviours higher up in the layer stack.
    – Evan Anderson
    Oct 27, 2009 at 12:57
  • Was the cable. Swapped it and now... 2348616 100% 18.81MB/s 0:00:00 (xfer#1, to-check=0/1) Thanks! +1
    – randomx
    Oct 27, 2009 at 13:54
  • Actually turned out to be a NIC configuration - duplex mismatch. Found "ethtool" which told me the NIC was 100half. The switch was 100Full.
    – randomx
    Oct 29, 2009 at 14:08
4

Is your NIC set to 100 full duplex too?

Are there any errors in the switch log?

Improve this answer
2
  • The NIC was 100 half even though the switch was 100 full. +1
    – randomx
    Oct 29, 2009 at 14:09
  • This is probably the most common cause of errors. I usually start here before looking at cables and bad cards or ports.
    – Doug Luxem
    Oct 29, 2009 at 14:46
1

Usually it's cabling or nic, if you have other systems on the network that are working with the switch then it may not be the switch. To test that you can just use other ports to see if the switch as a bad port or two on it (depending on which you switch out to a different port each time to test).

Patch cables first, then look at NICs, I'd say. If there's activity lights you can also check and see if something is slamming the switch, i.e., something infected on the network and flooding the switch's routing table. tcpdump or wireshark might tell you something about that.

Improve this answer
1

Consider that a collision is impossible on a microsegmented network running at full duplex. Perhaps they are not collisions, but ICMP Source Quench requests? More information here, here, and here. Lately, I have seen many newer devices reporting ICMP Source Quench requests as collisions.

Improve this answer
0

I found ethtool which allowed me to diagnose that my NIC auto-configured to 100/half. Changed it to full and was problems went away.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .