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/