Titian
asked on
TCP throughput low and asymmetric on windows
I've been using the trialware program "PerformanceTest 7.0", which has a module for testing network throughput.
I've discovered that when I use UDP, the speed is more or less the line speed between the two hosts. However, I've found that the TCP speed is much slower, and asymmetric. Note one of the hosts is an offsite server, 1ms ping away. I've tried to do the test against it from various machines of various specs/OS.
When the Windows Server 2008 machine is the sender, and the XP machine is the receiver, the speed is fast (but not UDP speed). The other way round, it's really, really slow.
Furthermore, I've used WireShark to look at the traffic. I've found numerous TCP duplicate ACKs and retransmissions in both scenarios, but it seems in the slower scenario, the sender waits by over a second roughly when the window size is reached, after a few frames. This doesn't happen the other way round. It also does this every few frames as the transmission goes on. Looking at the network benchmarking window, it seems as though the "data sent" only increments when a retransmission occurs.
The fast way wound, there's still load of resends, but no waiting, which I suppose is why the speed is higher (x10) but not quite as high as UDP.
What could be causing this? I've tried numerous fixes involving netsh commands on the 2008, changing the adapter settings on both, and changing registry settings on both. What do I need to be looking at? Note I've got many, many machines that I've tested this on, some with windows 7, some with windows XP, some with Windows 2008.
I've discovered that when I use UDP, the speed is more or less the line speed between the two hosts. However, I've found that the TCP speed is much slower, and asymmetric. Note one of the hosts is an offsite server, 1ms ping away. I've tried to do the test against it from various machines of various specs/OS.
When the Windows Server 2008 machine is the sender, and the XP machine is the receiver, the speed is fast (but not UDP speed). The other way round, it's really, really slow.
Furthermore, I've used WireShark to look at the traffic. I've found numerous TCP duplicate ACKs and retransmissions in both scenarios, but it seems in the slower scenario, the sender waits by over a second roughly when the window size is reached, after a few frames. This doesn't happen the other way round. It also does this every few frames as the transmission goes on. Looking at the network benchmarking window, it seems as though the "data sent" only increments when a retransmission occurs.
The fast way wound, there's still load of resends, but no waiting, which I suppose is why the speed is higher (x10) but not quite as high as UDP.
What could be causing this? I've tried numerous fixes involving netsh commands on the 2008, changing the adapter settings on both, and changing registry settings on both. What do I need to be looking at? Note I've got many, many machines that I've tested this on, some with windows 7, some with windows XP, some with Windows 2008.
ASKER
I don't think the CPU load is causing the problem. The line is only 10Mbit/s, and the tool is telling me CPU usage is just a few percent.
I'm not sure if the %-age of CPU load matters (unless it's already very high). The TCP traffic must be wrapped and unwrapped for every packet, error check, retransmit/recovery.
UDP lacks any order or flow control, so data can drop or arrive in the wrong order. Doesn't matter, the sender will keep sending without applying any controls that would normally slow down TCP/IP.
UDP lacks any order or flow control, so data can drop or arrive in the wrong order. Doesn't matter, the sender will keep sending without applying any controls that would normally slow down TCP/IP.
ASKER CERTIFIED SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
ASKER
It turns out the problem wasn't the configuration after all, it was the WAN provider.
If your network interface does not handle the TCP crunching (the NIC will say "TOE"), then your Windows OS must do it. Faster machines working in pure RAM will be faster than slower computers that are performing other tasks and possibly swapping memory operations out to a hard drive cache.
A NIC with TOE (TCP offload engine) will remove the load from the CPU.