lkml.org 
[lkml]   [1999]   [May]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch] TCP/IP delacks disabled with MPI
    On Mon, 24 May 1999, Andi Kleen wrote:

    >decremented by acks (and coincidentely we already have such a counter -
    >tp->packets_out / tcp_packets_in_flight). The send queue check is far
    >too costly.

    The packets_out and tcp_packets_in_flight and the send queue has nothing
    to do with the receiver delayed-acks. I am changing the receiver not the
    sender. The information I want is to know how many not-yet-acked packets
    are in the receive queue. The browse of the receive list will run in O(1)
    most of the time and looks a robust way to get such info.

    >But the trace shows that the problem is that sender doesn't get out of
    >slow start quickly enough because of the delacks. Now we already have

    No. The performance drop due breaking RFC1122 has nothing to do with the
    sender. Maybe also the sender should incrase cwnd by more than 1 but
    that's a different issue (and reading RFC it seems that the sender is ok
    by increasing cwnd only by 1).

    >a mechanism in 2.2 to work around that - quick ack mode. It gets enabled

    quick ack mode is not a mechanizm to work around that. It's just that when
    we got an OOO segment we want to ack immediatly the received packet to
    update the sender about our current rcv_nxt.

    quick ack is needed also for generating the first ack immediatly after the
    three way handshake.

    >Currently it only acks quickly a single packet (I believe that was been
    >done to optimize HTTP mainly), but that could be extended without too

    quickack is not only to ack fast the first packet after the three way
    handshake.

    >So I believe the right fix is to add a new sysctl that enlarges quick ack
    >mode to more packets.

    Could you show me how this trace will continue with your fix applyed?

    18:49:12.911613 localhost.1155 > localhost.3333: S 3745394879:3745394879(0) win 31072 <mss 3884,sackOK,timestamp 1616487 0,nop,wscale 0> (DF)
    18:49:12.911708 localhost.3333 > localhost.1155: S 3746598727:3746598727(0) ack 3745394880 win 31072 <mss 3884,sackOK,timestamp 1616487 1616487,nop,wscale 0> (DF)
    18:49:12.911751 localhost.1155 > localhost.3333: . ack 1 win 31072 <nop,nop,timestamp 1616487 1616487> (DF)
    18:49:12.911839 localhost.1155 > localhost.3333: P 1:2(1) ack 1 win 31072 <nop,nop,timestamp 1616487 1616487> (DF)
    18:49:12.911897 localhost.3333 > localhost.1155: . ack 2 win 31071 <nop,nop,timestamp 1616487 1616487> (DF)
    18:49:12.911934 localhost.1155 > localhost.3333: P 2:3(1) ack 1 win 31072 <nop,nop,timestamp 1616487 1616487> (DF)
    18:49:12.911966 localhost.1155 > localhost.3333: P 3:4(1) ack 1 win 31072 <nop,nop,timestamp 1616487 1616487> (DF)
    [??]

    The problem is that if you delay the ack until you'll have 2*MSS data
    queued, then you'll stall in [??] for `ato' time (that will be as best a
    10msec delay at such point). You'll stall because if the sender is not
    buggy, the sender will block in [??] because cwnd at such point is only
    equal to 2. Without my patch linux-receiver won't send an ack because it
    only had 2byte queued and not more than 2*MSS data. But RFC1122 clearly
    state that the receiver must send an ack at the _second_ packet, not after
    2*MSS unacked data is been queued.

    The sender has nothing to do with the issue. The sender is not linux but
    is a random OS that only knows about the slow start algorithm and follows
    rfc2001.txt word-by-word.

    I don't think my patch is the wrong thing to do at least by reading
    RFC1122. If rfc1122 is been obsoleted I would be glad if you would give me
    the url of a new spec. Thanks.

    Andrea Arcangeli


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:51    [W:4.659 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site