TCP Acknowledgement Frequency Configuration and Need Consultant in San Jose Area

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\Par ameters\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

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

"Will" <westes-(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ...
> 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\Par ameters\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
>

"Arkady Frenkel" <(E-Mail Removed)> wrote in message
news:OwsQ%(E-Mail Removed)...
> 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

SO_NODELAY option set on the socket with setsockopt()
Arkady

"Will" <westes-(E-Mail Removed)> wrote in message
news:07-(E-Mail Removed)...
> "Arkady Frenkel" <(E-Mail Removed)> wrote in message
> news:OwsQ%(E-Mail Removed)...
>> 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" <westes-(E-Mail Removed)> wrote in message
> news:07-(E-Mail Removed)...
>> "Arkady Frenkel" <(E-Mail Removed)> wrote in message
>> news:OwsQ%(E-Mail Removed)...
>>> 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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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.

--
Will