netdev
[Top] [All Lists]

Re: [patch] 2.4.9 new socket option TCP_DELACK (RFC)

To: nivedita@xxxxxxxxxxx (Nivedita Singhvi)
Subject: Re: [patch] 2.4.9 new socket option TCP_DELACK (RFC)
From: Alexey Kuznetsov <kuznet@xxxxxxxxxxxxx>
Date: Fri, 31 Aug 2001 03:28:53 +0400 (MSD)
Cc: netdev@xxxxxxxxxxx
In-reply-to: <200108280207.f7S275J18467@eng4.beaverton.ibm.com> from "Nivedita Singhvi" at Aug 28, 1 06:15:02 am
Sender: owner-netdev@xxxxxxxxxxx
Hello!

> - possibly better performance in certain environments

What exactly?

Well, actually, I have one question: how is application supposed
to determine, when it is in this "certain environment"?
I see no way, but already implemented in tcp.
In any case, if you can propose another way to guess, when
delayed acks harm performance, it should be added to set of heuristics.

Actually, opposite option would make sense, 2.4 really generates
too much of acks in some curcumstances. :-)


> - _very_ convenient for academic, benchmarking, and certain
>   other environments to use 

Benchmarking thing which happen only in academic environment
is not very cool idea.


> - portability: its available on some other OS's, and
>   so some apps that make use of it might want to continue
>   to use it on Linux when ported here..

Enlighten me, what OSes exactly? I would rather expect that applications
using this funny option are to be repaired not to use it.


> - makes the tcp engine more configurable based on what the
>   user wants to do, and the easier it is to fiddle with things, 
>   the more learning, innovation that happens on the OS, and 
>   I'd like to encourage that happening on Linux ;)

Sigh, the word "innovation" would make sense if you proposed a way
to generate ACKs more cleverly, rather than more silly. :-) :-)


One comment to improve your patch:


> @@ -3015,7 +3015,8 @@
>       struct tcp_opt *tp = &(sk->tp_pinfo.af_tcp);
>  
>           /* More than one full frame received... */
> -     if (((tp->rcv_nxt - tp->rcv_wup) > tp->ack.rcv_mss
> +     if (tp->ack.no_delack ||
> +         ((tp->rcv_nxt - tp->rcv_wup) > tp->ack.rcv_mss
>            /* ... and right edge of window advances far enough.
>             * (tcp_recvmsg() will send ACK otherwise). Or...
>             */


The place is wrong. If done at all, this should be done
in tcp_recvmsg() to wait for reopening window at least.
Otherwise each segment will generate double ACK: one of them
is totally useless, because it does not move right edge of window.

Also, you can improve it removing checks from data path.
You can obtain required effect blocking setting tp->ack.pingpong.
tp->ack.pingpong frozen at zero gives maximal reasonable ack frequency.

Alexey

<Prev in Thread] Current Thread [Next in Thread>
  • Re: [patch] 2.4.9 new socket option TCP_DELACK (RFC), Alexey Kuznetsov <=