Messages in this thread Patch in this message | | | From | Stanislav Meduna <> | Subject | TCP window updates [Was: PROBLEM: Sending mail-attachment] | Date | Sat, 27 Feb 1999 19:10:51 +0100 (CET) |
| |
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/
| |