Big time delay for ACK packets, both sent and received

asked 2018-07-03 14:37:26 +0000

Rowandish
3 ●1 ●1 ●3

updated 2018-07-04 12:43:43 +0000

Hi all,

I have to send some data to a server on a PC directly linked to mine, but I find that the connection is quite slow (500ms to send simple data) and I'm trying to figure out where are the problems.

It is a local connection, from a PC to another, so no override from router, switch and so on.

Here is a snapshot of a POST request from 192.168.1.1 to http://192.168.1.2/esito using POST:

Snapshot

Direct link to image.

The column time indicates the time from the previous packet: as you can see there are 2 quite slow packets: the number 5 from the destination to the source and the number 8 from the source to the destination.

Both of the packets are communication ACK packets, I'm wondering why ACK packets can be slower that the real request packets (number 6 and 7).

Here you can find the pcapng captured data.

Is there a way to debug the problem further? How could I increase the speed of the communication?

SOLUTION

As NJL and Packet_vlad said it was TCP Delayed Acknowledgement with Nagle algorithm.

Both of the PC are Windows so in order to fix it you have to add the following DWORD registry keys both on the sender and to the receiver:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{NIC-id}

TcpAckFrequency -> 1
TCPNoDelay -> 1

I added also the following code in my C# .NET based software:

var service = ServicePointManager.FindServicePoint(new Uri("http://192.168.1.2"));
service.UseNagleAlgorithm = false;

Here you can find the new wireshark captured data with almost no delay in ACKs.

edit retag flag offensive close merge delete

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2018-07-03 16:22:51 +0000

NJL
120 ●2 ●24 ●8

To me it looks like both 192.168.1.1 and 192.168.1.2 is using Delayed ACK. This can be seen in all the "naked" ACKs (i.e. no TCP payload) sent by 192.168.1.2 (packet 5, 8, 10, 13, 15 etc.). Make sure you create a new "Delta Time Displayed" Column in order to identify the time it takes between two packets in the capture. To do this (if you don't already know) you right-click in the column header and select Column Preferences. Here you click the "+" icon and fill out the Title field and in the Number field you select "Delta time displayed". I recommend you disable Delayed ACK. Don't know what OS you're running so I won't provide any help on this. Google is your friend here.

It also looks as if 192.168.1.1 is running the Nagle algorithm. This can be seen in packet 9, 14, 19, 24. You should also look up how to disable this - but please verify that it is indeed enabled before you start changing the settings :-)

If Delayed ACK and Nagle is NOT enabled then my immediate alternate theory is that both devices are short on CPU ressources or otherwise constrained, although none of them seem to be doing much else on the network apart from this conversation, so I consider this highly unlikely.

Please do return with feedback on your findings and (hopefully) a solution.