Messages in this thread | | | Date | Tue, 9 Mar 1999 04:32:48 +0100 (CET) | From | Matthias Moeller <> | Subject | Re: TCP window updates [Was: PROBLEM: Sending mail-attachment] |
| |
On Tue, 9 Mar 1999, Andrea Arcangeli wrote:
> I think the point is that we should set the probe0 timer even if the > sending-window is not 0. This should be the timeout that the rfc1122 that > you quoted yesterday talks about.
Yes and the kernel actually does this. Otherwise we would see much more stalls. For every incoming ACK it calls tcp_data_snd_check(). This either puts new data on the wire or starts the PROBE0 timer. But if there is currently no data on the write queue (skb==NULL) the function does nothing. This is the only case where the stall can happen.
New data arrives via tcp_v4_sendmsg() and for write sizes < mss no data is put on the wire and the PROBE0 timer is not started.
> What looks to me wrong is that in the queue_it case (the queue_it case > should deal with resembling iovect in full-mss-sized packets) we are not > setting the probe0 timer in tcp_send_skb.
Agreed.
> > So to have always a probe0 timer pending when we are only queueing data I > think we should do this as you suggested: > > Index: tcp_output.c > =================================================================== > RCS file: /var/cvs/linux/net/ipv4/tcp_output.c,v > retrieving revision 1.1.2.12 > diff -u -r1.1.2.12 tcp_output.c > --- tcp_output.c 1999/03/08 13:27:44 1.1.2.12 > +++ tcp_output.c 1999/03/08 23:30:28 > @@ -177,7 +177,7 @@ > /* Queue it, remembering where we must start sending. */ > if (tp->send_head == NULL) > tp->send_head = skb; > - if (!force_queue && tp->packets_out == 0 && !tp->pending) { > + if (tp->packets_out == 0 && !tp->pending) { > tp->pending = TIME_PROBE0; > tcp_reset_xmit_timer(sk, TIME_PROBE0, tp->rto); > } > > > But I am not 100% sure this is enough to make sure to always have a probe0 > timer pending if there's some data pending not yet transmitted and we are > waiting for a window update before transmitting data.
Im quite sure. The patch looks fine for me. I actually tried this some days ago , it fixed the stalls even with the broken cleanup_rbuf() function.
> Another thing that make me ill ;) is the fact that tcpdump screw up things > while your proggy is running on the loopback device. Now I am going to > debug _why_ this happens.
I have the same problem with tcpdump on lo. It shows not all frames.
Matthias
- 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/
| |