Re: TCP_DELACK_MIN vs TCP_ATO_MIN
On Wed, Sep 21, 2011 at 8:58 PM, Daniel Baluta wrote: > > Now the default value is of both the macros is same. > > > > But if you want to make delayed ack timeout configurable, then I think > you > > should give proc interface for TCP_DELACK_MIN. > > Thanks Rohan. Then also I have to export TCP_DELACK_MAX since I think > ato cannot grow over this value. > > thanks, > Daniel. > Yes Daniel. Regards, Rohan Puri ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: TCP_DELACK_MIN vs TCP_ATO_MIN
> Now the default value is of both the macros is same. > > But if you want to make delayed ack timeout configurable, then I think you > should give proc interface for TCP_DELACK_MIN. Thanks Rohan. Then also I have to export TCP_DELACK_MAX since I think ato cannot grow over this value. thanks, Daniel. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: TCP_DELACK_MIN vs TCP_ATO_MIN
On Wed, Sep 21, 2011 at 6:29 PM, Daniel Baluta wrote: > Hello, > > RFC2582, Section 4.2 says: > > "... an ACK SHOULD be generated for at least every second > full-sized segment, and MUST be generated within 500 ms > of the arrival of the first unacknowledged packet. ". > > > I guess that the delayed ACK timeout is computed in tcp_send_delayed_ack: > > === > void tcp_send_delayed_ack(struct sock *sk) > { >struct inet_connection_sock *icsk = inet_csk(sk); >int ato = icsk->icsk_ack.ato; >unsigned long timeout; > > /* */ >/* Stay within the limit we were given */ >timeout = jiffies + ato; > > > > Can one explain what is the difference between TCP_DELACK_MIN and > TCP_ATO_MIN, specifically if the timeout (ato) is always in the interval > [TCP_DELACK_MIN, TCP_DELACK_MAX] ? > > I want to make the delayed ack timeout configurable as some guys tried > here [1], > so for this reason I plan to make TCP_DELACK_MIN and TCP_DELACK_MAX > tunable via proc entries. > > thanks, > Daniel. > > [1] http://kerneltrap.org/mailarchive/linux-netdev/2008/9/9/3245554 > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > Hi Daniel, TCP in linux makes use of two modes for acking the data received. 1. Quick Ack : - Used at the start of the TCP connection so that the congestion window can grow fastly. 2. Delayed Ack : - It moves to delayed ack mode, in which ack is sent for multiple packets. TCP switches between the two modes depending on the congestion experienced. In Quick Ack, Ack timeout interval (ato) is set to minimum i.e. TCP_ATO_MIN while in Delayed Ack mode, TCP_DELACK_MIN is used for restarting/ resetting the timer. Now the default value is of both the macros is same. But if you want to make delayed ack timeout configurable, then I think you should give proc interface for TCP_DELACK_MIN. Regards, Rohan Puri ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
TCP_DELACK_MIN vs TCP_ATO_MIN
Hello, RFC2582, Section 4.2 says: "... an ACK SHOULD be generated for at least every second full-sized segment, and MUST be generated within 500 ms of the arrival of the first unacknowledged packet. ". I guess that the delayed ACK timeout is computed in tcp_send_delayed_ack: === void tcp_send_delayed_ack(struct sock *sk) { struct inet_connection_sock *icsk = inet_csk(sk); int ato = icsk->icsk_ack.ato; unsigned long timeout; /* */ /* Stay within the limit we were given */ timeout = jiffies + ato; Can one explain what is the difference between TCP_DELACK_MIN and TCP_ATO_MIN, specifically if the timeout (ato) is always in the interval [TCP_DELACK_MIN, TCP_DELACK_MAX] ? I want to make the delayed ack timeout configurable as some guys tried here [1], so for this reason I plan to make TCP_DELACK_MIN and TCP_DELACK_MAX tunable via proc entries. thanks, Daniel. [1] http://kerneltrap.org/mailarchive/linux-netdev/2008/9/9/3245554 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies