# Revision history [back]

### Big time delay for ACK packets, both sent and received

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:

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?

### Big time delay for ACK packets, both sent and received

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:

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:

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.

### Big time delay for ACK packets, both sent and received

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:

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: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.