This is our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.
0
1

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's gravatar image

RenniePet
11237
accept rate: 0%


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.

netsh interface tcp set supplemental template=custom minRto=20 icw=16 delayedacktimeout=10

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:

netsh interface tcp set supplemental template=custom

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.
The (duplicate) ACKs indicate that only the second half of the large segment was received by the android's TCP layer. So with the receipt of duplicate ACKs indicating packet loss your windows reverts back to normal sending of segments for a while until it retries segmentation offload with the same results, being the first segment never arrives resulting in 3 dup_ACKs and fast retransmission.

(tcp.analysis.duplicate_ack_num == 3 or tcp.len gt 1448) and tcp.stream eq 0

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

permanent link

answered 09 Oct '15, 08:34

mrEEde's gravatar image

mrEEde
3.9k152270
accept rate: 20%

edited 13 Oct '15, 22:43

Great hotfix link.

(10 Oct '15, 01:50) Christian_R

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.

(12 Oct '15, 22:22) RenniePet

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?

(15 Oct '15, 15:02) RenniePet

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?

(15 Oct '15, 15:19) Christian_R

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.

(15 Oct '15, 15:37) RenniePet

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.

(15 Oct '15, 15:43) Christian_R
1

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.

(16 Oct '15, 05:50) RenniePet
1

You are welcome. And I have learned, too. E.g. : A great link -> thanks @mrEEde

(16 Oct '15, 06:09) Christian_R
showing 5 of 8 show 3 more comments
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×104
×37

question asked: 09 Oct '15, 06:23

question was seen: 2,743 times

last updated: 16 Oct '15, 06:11

p​o​w​e​r​e​d by O​S​Q​A