Re: TcpAckFrequency

"Eugene Firsov" <a@xxx> wrote in message
news:BDF6E023-036A-4602-AAF5-5229053DBFD6@xxxxxxxxxxxxxxxx
According to Microsoft, the parameter TcpAckFrequency in

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{Interfac
e
ID} says how many received TCP packets should be acknoleged. By default it
is equal to 2. That means that every other packet will be acknoleged. When
I
set this parameter to some large number, for example 200, I should expect
that every 200th packet will be acknoleged. But in my experiments with
Network Monitor I see that acknolegement is still sent after 5-10 packets.
Why? How can I significally reduce the number of ack packets?

Eugene


You're probably seeing the expiration of the delayed ACK timer, which
defaults to 200 milliseconds. Increase the value of TcpDelAckTicks to see
if that makes a difference.

But why do you see a need to reduce the number of ACKs? If you reduce the
number of ACKs too far, you will probably start to experience spurious
retransmissions from the sender. The sender is expecting an ACK within the
retransmission timeout (RTO) and if you delay sending the ACK for too long,
the sender will make spurious retransmissions of data that the recipient
already has but has not yet acknowledged. These spurious retransmissions
are likely to create more traffic on the network than you could ever expect
to offset by reducing the amount of ACK traffic.


.

Relevant Pages

  • Re: Socket weirdness
    ... Anyway, if the application on one device does Shutdownthen if a packet containing data is received from the peer on that connection, then that is an not a valid packet and a packet with the RST bit set is sent clearing down the connection. ... In TCP there is simply *one* type of packet, this is unlike HDLC, which carries data in 'I' frames, has ACK frames which it calls 'RR', and lots more. ... And receiving a segment containing data is not valid where the local application has done shutdown). ...
    (microsoft.public.dotnet.framework)
  • Re: Interesting TCP behaviour with large sends/small buffers
    ... The server, upon connection, sends a configurable number of bytes to ... I set the client's receive buffer size to 1MBps, ... packet before sending the next packet. ... ACK, according to the delayed ACK algorithm - 50KB bytes means 34 MSS- ...
    (microsoft.public.win32.programmer.networks)
  • Re: Interesting TCP behaviour with large sends/small buffers
    ... TCP converter I've been working on, in which data arrives at specific ... I set the client's receive buffer size to 1MBps, ... packet before sending the next packet. ... ACK, according to the delayed ACK algorithm - 50KB bytes means 34 MSS- ...
    (microsoft.public.win32.programmer.networks)
  • Re: Interesting TCP behaviour with large sends/small buffers
    ... The server, upon connection, sends a configurable number of bytes to ... I set the client's receive buffer size to 1MBps, ... packet before sending the next packet. ... ACK, according to the delayed ACK algorithm - 50KB bytes means 34 MSS- ...
    (microsoft.public.win32.programmer.networks)
  • Re: 8159 bytes takes 20 ms, 8160 bytes takes 200 ms?
    ... the ACK packet. ... Flags: 0x04 (Don't Fragment) ... Header checksum: 0x9ac7 ...
    (microsoft.public.win32.programmer.networks)