Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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:  Bcast:  Mask:
          inet6 addr: fe80::230:48ff:fe2e:a378/64 Scope:Link
          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?

share|improve this question
Replace HUBs in your network with switches :)))) – kolypto Oct 29 '09 at 0:44

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.

share|improve this answer
I'm hoping for a configuration fix before I go for the OSI model. :-) – randy melder Oct 27 '09 at 12:32
@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 '09 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 – randy melder Oct 27 '09 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. – randy melder Oct 29 '09 at 14:08

Is your NIC set to 100 full duplex too?

Are there any errors in the switch log?

share|improve this answer
The NIC was 100 half even though the switch was 100 full. +1 – randy melder Oct 29 '09 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 '09 at 14:46

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.

share|improve this answer

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.

share|improve this answer
up vote 0 down vote accepted

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.