Slow TCP/IP performance from VSE to Windows.

Resolving The Problem

What we discovered while looking at the sniffer trace and running tests is that the Windows 2000 system is waiting 200 milliseconds before sending an ACK (acknowledgments).  Microsoft introduced a new feature called Delay Acknowledgments created to reduce the number of packets sent on the media.  Instead of sending an ACK for each TCP segment, it sends an ACK after every other frame.

The reason for the slow performance is a combination of settings within their network and how Microsoft Windows 2000 handles receiving packets.  The sniffer trace showed three packets (real data); these packets are carrying 4096 bytes of data; In Windows, the first two packets are received, and immediately acknowledged; the third packet hits the delayed acknowledgement logic, and it is only acknowledged after the 200 ms interval has expired. Since a new 4096 buffer will only be written to the TCP/IP stack after the previous transmission is acknowledged, the delay on the third packet is extremely costly. The sniffer showed it took  VSE less than 6 ms to send out the three packets; then we had a delay of about 200ms. It is obvious that the delay is THE major problem here.

This default setting can be changed with a registry key (TCPDelAckTicks).   

We have tested the above and were able to duplicate the slow transfer.  We resolved the slow transfer by adding the registry key in Windows (TCPDelAckTicks) and setting it to zero (0).  But keep in mind that two or more ACK will be sent after every packet, which adds more traffic to the network.  Another way of correcting the slow transfer is to make sure the negotiated buffer size can be evenly divided by the frame size coming across the line.  This is the preferred method to work around this networking issue, since changing the TCPDelAckTicks could adversely affect the entire network.  The goal is to make sure each packet is paired up or in pairs.  This is to prevent the Delay Acknowledgements from taking place waiting 200 milliseconds. 

This is how Microsoft explains this feature:

DELAY ACKNOWLEDGMENTS

As specified in RFC 1122, TCP uses delayed acknowledgments (ACKs) to reduce the number of packets sent on the media.  Rather than sending an acknowledgment for each TCP segment received, Windows 2000 TCP takes a common approach to implementing delayed ACKs.  As data is received by TCP on a given connection, it only sends an acknowledgment back if one of the following conditions is met:

 No ACK was sent for the previous segment received.
 A segment is received, but no other segment arrives within 200 milliseconds for that connection.

Normally an ACK is sent for every other TCP segment received on a connection, unless the delayed ACK timer (200 milliseconds) expires.  The delayed ACK timer for each interface can be adjusted by setting the value of the TCPDelAckTicks registry entry
(HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\<interface>).