lkml.org 
[lkml]   [1999]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    SubjectTCP window updates [Was: PROBLEM: Sending mail-attachment]
    Date
    Hello once more,

    I did some more tests with the TCP stall problem.

    > 13:53:20.339402 lh.3333 > lh.1284: P 25161:26641(1480) ack 1 win 31072 (DF)
    > 13:53:20.339402 lh.3333 > lh.1284: P 25161:26641(1480) ack 1 win 31072 (DF)
    > 13:53:20.339450 lh.1284 > lh.3333: . ack 26641 win 4432 (DF)
    > 13:53:20.339450 lh.1284 > lh.3333: . ack 26641 win 4432 (DF)
    > 13:53:20.339864 lh.3333 > lh.1284: P 26641:28121(1480) ack 1 win 31072 (DF)
    > 13:53:20.339864 lh.3333 > lh.1284: P 26641:28121(1480) ack 1 win 31072 (DF)
    > 13:53:20.339903 lh.1284 > lh.3333: . ack 28121 win 2952 (DF)
    > 13:53:20.339903 lh.1284 > lh.3333: . ack 28121 win 2952 (DF)
    > 13:53:20.340299 lh.3333 > lh.1284: P 28121:29601(1480) ack 1 win 31072 (DF)
    > 13:53:20.340299 lh.3333 > lh.1284: P 28121:29601(1480) ack 1 win 31072 (DF)
    > 13:53:20.340337 lh.1284 > lh.3333: . ack 29601 win 1472 (DF)
    > 13:53:20.340337 lh.1284 > lh.3333: . ack 29601 win 1472 (DF)
    === stall ===


    I digged into the networking code for the first time,
    but could it possibly be something like this?

    - the data flow in one direction only, so there
    are no data packets carrying the receiver window

    - the sender must thus get the window in the
    ack packets

    - the receiver window can enlarge on two places
    - in __tcp_ack_snd_check (tcp_raise_window called)
    - in cleanup_rbuf when something was read

    - the __tcp_ack_snd_check will be called from
    tcp_ack_snd_check iff there are some delayed acks,
    which (according to tcpdump) probably isn't the case
    and from tcp_rcv_established (which I don't understand :-))

    If there are no delayed acks and the call from
    tcp_rcv_established does not enlarge the window
    (this is I think before the data get read),
    the cleanup_rbuf must do this after the read.
    If it doesn't do it, then there is nobody more
    who can do it. The window will never get enlarged
    and when it drops to sufficient size, the
    connection stalls. The sender won't send the
    data into window smaller than the data are.

    - So I suspected cleanup_rbuf and blindly commented
    out one of the test:

    diff -uNr linux-2.2/net/ipv4/tcp.c linux-ac/net/ipv4/tcp.c
    --- linux-2.2/net/ipv4/tcp.c Tue Feb 23 19:59:10 1999
    +++ linux-ac/net/ipv4/tcp.c Sat Feb 27 18:42:38 1999
    @@ -1077,7 +1077,8 @@
    * checks are necessary to prevent spurious ACKs
    * which don't advertize a larger window.
    */
    - if((copied >= rcv_window_now) &&
    + /* Stano */
    + if(/* (copied >= rcv_window_now) && */
    ((rcv_window_now + tp->mss_cache) <= tp->window_clamp))
    tcp_read_wakeup(sk);
    }
    Frankly, I don't know what I made - the condition just
    seemed suspicious to me. It works - the stalls are away.

    I doubt that this is the correct fix but hopefully
    the networking hackers can analyse the real reason.

    Regards
    --
    Stano


    -
    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:50    [W:0.034 / U:92.848 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site