Very slow TCP speed and throughtput in contast to UDP

Question

I have been monitoring a 1 Gbps OM2 fiber connection to one switch we have with Smokeping... There seems to be an avg loss of 3-4% for a few days now..

Started troubleshooting using iperf, having set window size to 65K...Just to cross-check i used pathtest using the same window size...Both report speeds below 10 Mbps (!) which surely are unacceptable, considering a logical transfer rate would be at around 1/4 of the Gpbs connection when PCI NIC's are used and in terms of in-memory transfers...

UDP tests, on the other hand, from both iperf and smokeping report speeds between 300-400 Mbps and as far as reading and writing using LanSpeed i get a respective 55-65 Mbps and 20 Mbps...

Having read that iperf's implementation on Windows is not a reliable one i now think that testing using that tool was wrong in the first place with Windows...

Machines used for testing were Windows XP (client) > Windows XP (server)...all NICs have auto in terms of negotiation and reporting pre-negotiated speed of lan link at 1 Gbps...no mdix errors or up/downs shown on syslog... MTU at 1500... Quick Rawcap trace and trace analysis with Wireshark shows TCP Zero Window errors which clearly explain the significant drop on TCP throughput...

Switch is an SG200-50, poor on out-of-band management facilities and cli, so, for now, not much to see except under web interface...already disabled zero-DNS servics like Bonjour.....

Any suggestions greatly appreciated...

Answer 1

As Ron said, 3-4% packet loss is incredibly high. ThousandEyes ran some experiments on the effects of packet loss and found anything over ~0.5% is hugely detrimental. see: https://blog.thousandeyes.com/a-very-simple-model-for-tcp-throughput/

Hopefully replacing the fiber patch (make sure to clean it first!) will help. Otherwise start looking into other sources for the loss.

Answer 2

The answer is in your question :) TCP Zero Window means that the data flow is going to grind to a halt until the receiving end's buffer is cleared enough to receive more data. In other words you're network connection is working just fine, it's your PC/server that's the problem. Have a read of this link.

Troubleshooting a Zero Window For one reason or another, the machine alerting the Zero Window will not receive any more data from the host. It could be that the machine is running too many processes at that moment, and its processor is maxed. Or it could be that there is an error in the TCP receiver, like a Windows registry misconfiguration. Try to determine what the client was doing when the TCP Zero Window happened.

The reason why you're not seeing the same problem with UDP is because it is connectionless and therefore it does not know nor care whether the remote end has buffers available, it will continue sending more data anyway.

My suggestion is to first ensure that the hosts you're using for testing have sufficient RAM and CPU, and if they do, try testing from a couple of different hosts. The fact is that it's not the network connection which is holding you back, it's that your host(s) are not processing the received data quickly enough which is therefore delaying their ACKs which in turn is slowing your connection down.