New user here, and my knowledge of TCP/IP is not good. Here's the WireShark capture: https://www.cloudshark.org/captures/7133e5f96577 The connection is between my PC and an Android device on WiFi. I'm developing my own TCP/IP modules for both ends. I think the PC module is OK - PC-to-PC communications works fine. Android-to-PC also works OK, but PC-to-Android is very slow, down around 10% of the speed in the other direction. I've run an Android app called SpeedTest, and it indicates that the WiFi connection is OK, with speed in both directions about the same. So in desperation I've tried using WireShark to see what is going on. There are tons of Retransmission and Dup ACK packets. I assume this is what is causing the performance to be so poor, right? (10.2.2.20 is my PC, 172.16.31.178 is the Android device.) I'm also assuming my Android programming must be faulty. I'm using Java NIO, if that's relevant. Does anyone have any suggestions as to what is wrong, to cause these symptoms? Thanks in advance. asked 09 Oct '15, 06:23  RenniePet |
One Answer:
You are correct, the timer based (= delayed) retransmissions after packet loss are what is hurting performance. So you either need to avoid the packet loss or tune your windows to react faster on it. There is a hotfix out there that allows to reduce the minRTO value in Windows: http://support.microsoft.com/kb/2472264 " ... For example, you can use the following command to set the values for the Custom template. Note You have to tell the stack to use these Custom template values. The default template that the stack uses is the Internet template. Set the Custom template to be the global default template by using the following command: Note This command makes the custom values valid for all connections. " "Why does my PC choose to send small packets to the WiFi router and large packets to the other PC? I'm perhaps misunderstanding something, but the end result is that sending data to the Android device via the WiFi router is very slow, compared with everything else." Your PC starts out using Large-Send (TCP Segmentation Offload) however none of those 'large' packets make it to the android device. I would suggest to turn off Segmentation Offload / TCP Chimney Offload as per How to enable and disable TCP Chimney Offload in Windows Server 2008 to see if it helps avoid the packet loss over WiFi towards the android TCP layer. Regards Matthias answered 09 Oct '15, 08:34  mrEEde edited 13 Oct '15, 22:43 showing 5 of 8 show 3 more comments |
Great hotfix link.
Thanks for your answer.
As I mention, I don't know enough about TCP, but have been reading up on it the last couple of days.
Unfortunately, I don't think your answer is relevant to my problem. In fact, I don't think the Retransmission and Dup ACK packets are relevant either - so I was (probably) wrong on that point, and should not have made that part of my question.
What I'm seeing in this Wireshark log is that sending to the WiFi router (a SonicWall firewall / WiFi router) results in one packet of typically 1.5 KB every 2 ms. or so, while sending to another PC on the network results in one packet of 15 KB every 1 ms. or so.
Why does my PC choose to send small packets to the WiFi router and large packets to the other PC? I'm perhaps misunderstanding something, but the end result is that sending data to the Android device via the WiFi router is very slow, compared with everything else.
Matthias, thank you very much. Your last suggestion about turning off the TCP Chimney Offload does indeed fix the problem.
Strangely, for my system (Windows 7 64-bit) turning this option off via the command prompt simply doesn't work. (And yes, I did run command prompt as administrator. I even rebooted the PC to see if that made it work, but no.) When I display the parameters it says "disabled", but I still have the problem. It was first when I disabled the corresponding option for the network card that my problem was fixed.
So now I have a new question, if you'll bear with me. Is this a very rare situation I find myself in? Because I don't feel I can expect the customers of my program to be willing to do something like this, and it's apparently not something I can do via programming. Or is it? Can I specify a max packet size of 1448 bytes somewhere and fix it that way, so the fix is only for my program and not system-wide?
From my point of view it was a little bit strange what we have seen in the trace. So have you ever tried to use an actual nic driver?
Sorry, I don't understand what you mean. My PC program is written in C#, and uses .Net's SocketAsyncEventArgs, which uses the corresponding Windows API, which uses whatever network card driver and network card that happens to be installed in the machine. For my development machine it's a "Realtek PCIe GBE Family Controller". But when my program gets installed at a customer site it could be any network card and driver that the customer machine has.
So normally TCP Offloading should be no problem. But in the past a lot of problems with TCP Offloading has been caused by network drivers. And I thought you only had problems in this special case?! Am I wrong? If I am not wrong, than try to update the Realtek driver and try again with activated TCP Offloading.
@Christian_R: OK, I updated the driver and re-enabled the TCP offloading and now everything works. So I've wasted about three days due to a defective driver. Sigh. At least I've learned a lot about TCP and Wireshark. Thanks for your help.
You are welcome. And I have learned, too. E.g. : A great link -> thanks @mrEEde