TCP Acknowledgement Frequency Configuration and Need Consultant in San Jose Area

[Will]

We are having severe file server performance issues in a Windows network,
and I need some help in diagnosing behavior I am seeing.

Windows 2003 clients and servers can alter the default TCP ACK frequency by
setting a value named TcpAckFrequency for each specific adapter located in
the registry key:

\\HKLM\system\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{999...999}

The value of TcpAckFrequency is the number of packets after which a TCP ACK
is sent. Higher values for TcpAckFrequency mean fewer ACKs are being sent
out.

In the following report, the client is Windows 2003 and the server is
Windows 2000. I can change TCP ACK behavior on the client and not on the
server. Server runs on a 10/100 ethernet and client is on a gigabit
ethernet.

On the client, TcpAckFrequency defaults to 2. At this setting, copying a
250 MB file from the server takes 45 seconds. That's not a terrible
result, but I'm just establishing a baseline.

Microsoft Windows 2003 performance guidelines recommends a setting for TCP
ACK of 13 for gigabit Ethernet. Setting TcpAckFrequency to 13 on the
client yields copy time of 20+ minutes!!

Microsoft recommends a TCP ACK setting of 5 for 10/100 networks. Setting
to 5 yields copy time of 18 minutes!!

I tried going the other direction and setting to TcpAckFrequency of 1.
This yields copy time of 2 minutes.

Finally, I tried setting to TcpAckFrequency of 3. This yields copy time of
13 minutes.

Can someone explain to me why increasing the TcpAckFrequency even slightly
is completely destroying performance of this file copy? The result is
very surprising to me.

On a related note, I am looking for a TCP expert who is also a Windows
networking expert in the South San Francisco Bay Area to help us out on this
problem. We are having numerous strange anomalies, including file copies
that just terminate without finishing, and it is obvious something fairly
serious is broken. If you are interested in doing that work as a
contractor please forward resume to westes AT earthbroadcast.com.

[Arkady Frenkel]

Setting TcpAckFrequency to 13 mean that you ignore delault TcpDelAckTicks of
200 ms and miniport send it after 13 packets, so maybe such delay much
bigger than 200 ms, only after that ( due to Nagle algorithm ) peer can
continue to send next packet of the data.
You can remove Nagle on peer socket and check what happen but that generally
strongly not recommended practice.
Arkady

Post by Will
We are having severe file server performance issues in a Windows network,
and I need some help in diagnosing behavior I am seeing.
Windows 2003 clients and servers can alter the default TCP ACK frequency
by setting a value named TcpAckFrequency for each specific adapter located
\\HKLM\system\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{999...999}
The value of TcpAckFrequency is the number of packets after which a TCP
ACK is sent. Higher values for TcpAckFrequency mean fewer ACKs are being
sent out.
In the following report, the client is Windows 2003 and the server is
Windows 2000. I can change TCP ACK behavior on the client and not on the
server. Server runs on a 10/100 ethernet and client is on a gigabit
ethernet.
On the client, TcpAckFrequency defaults to 2. At this setting, copying a
250 MB file from the server takes 45 seconds. That's not a terrible
result, but I'm just establishing a baseline.
Microsoft Windows 2003 performance guidelines recommends a setting for TCP
ACK of 13 for gigabit Ethernet. Setting TcpAckFrequency to 13 on the
client yields copy time of 20+ minutes!!
Microsoft recommends a TCP ACK setting of 5 for 10/100 networks. Setting
to 5 yields copy time of 18 minutes!!
I tried going the other direction and setting to TcpAckFrequency of 1.
This yields copy time of 2 minutes.
Finally, I tried setting to TcpAckFrequency of 3. This yields copy time
of 13 minutes.
Can someone explain to me why increasing the TcpAckFrequency even slightly
is completely destroying performance of this file copy? The result is
very surprising to me.
On a related note, I am looking for a TCP expert who is also a Windows
networking expert in the South San Francisco Bay Area to help us out on
this problem. We are having numerous strange anomalies, including file
copies that just terminate without finishing, and it is obvious something
fairly serious is broken. If you are interested in doing that work as a
contractor please forward resume to westes AT earthbroadcast.com.
--
Will

[Will]

Post by Arkady Frenkel
Setting TcpAckFrequency to 13 mean that you ignore delault TcpDelAckTicks
of 200 ms and miniport send it after 13 packets, so maybe such delay much
bigger than 200 ms, only after that ( due to Nagle algorithm ) peer can
continue to send next packet of the data.
You can remove Nagle on peer socket and check what happen but that
generally strongly not recommended practice.

How would I remove Nagle on the peer socket?

[Arkady Frenkel]

SO_NODELAY option set on the socket with setsockopt()
Arkady

Post by Will

Post by Arkady Frenkel
Setting TcpAckFrequency to 13 mean that you ignore delault TcpDelAckTicks
of 200 ms and miniport send it after 13 packets, so maybe such delay much
bigger than 200 ms, only after that ( due to Nagle algorithm ) peer can
continue to send next packet of the data.
You can remove Nagle on peer socket and check what happen but that
generally strongly not recommended practice.

How would I remove Nagle on the peer socket?
--
Will

[Will]

Post by Arkady Frenkel

Post by Will

Post by Arkady Frenkel
Setting TcpAckFrequency to 13 mean that you ignore delault
TcpDelAckTicks of 200 ms and miniport send it after 13 packets, so maybe
such delay much bigger than 200 ms, only after that ( due to Nagle
algorithm ) peer can continue to send next packet of the data.
You can remove Nagle on peer socket and check what happen but that
generally strongly not recommended practice.

How would I remove Nagle on the peer socket?

SO_NODELAY option set on the socket with setsockopt()
Arkady

So obviously this isn't a practical solution for any problem I presented.
I'm not going to rewrite Microsoft's code, and the problem I reported was
with the COPY command and any other process that uses the OS primitives
required for file copying from a file server to a client.