I applied the following patch to 1.3.73 and 1.3.84. The bug disppeared in both
Kernel versions.
Studying the behaviour over a dialup link made me think about some other problems that I have
noticed since a long time under linux:
- catting a long file via a dialup link leads to a stuttering display of the contents of the
file (mtu 597). Sometimes the display stops for a second or more! (On an otherwise idle system..)
- Even on a LAN sometimes pauses develop in the display of characters.
Do we have someone who can troubleshoot the tcp stuff? I dont know what effect the
change in tcp.c has. Just found it by trial and error.
--- tcp.c.new Sat Apr 6 18:52:10 1996
+++ tcp.c Sat Apr 6 20:24:19 1996
@@ -1347,6 +1347,7 @@
static inline void tcp_eat_skb(struct sock *sk, struct sk_buff * skb)
{
+ sk->ack_backlog++;
skb->sk = sk;
__skb_unlink(skb, &sk->receive_queue);
kfree_skb(skb, FREE_READ);
@@ -1362,6 +1363,7 @@
static void cleanup_rbuf(struct sock *sk)
{
struct sk_buff *skb;
+ unsigned long rspace;
/*
* NOTE! The socket must be locked, so that we don't get
@@ -1373,10 +1375,51 @@
tcp_eat_skb(sk, skb);
}
- /* If we raised the window due to cleaning up, tell the world.. */
- if (tcp_raise_window(sk)) {
- sk->ack_backlog++;
+ /*
+ * FIXME:
+ * At this point we should send an ack if the difference
+ * in the window, and the amount of space is bigger than
+ * TCP_WINDOW_DIFF.
+ */
+
+ rspace=sock_rspace(sk);
+ if(sk->debug)
+ printk("sk->rspace = %lu\n", rspace);
+ /*
+ * This area has caused the most trouble. The current strategy
+ * is to simply do nothing if the other end has room to send at
+ * least 3 full packets, because the ack from those will auto-
+ * matically update the window. If the other end doesn't think
+ * we have much space left, but we have room for at least 1 more
+ * complete packet than it thinks we do, we will send an ack
+ * immediately. Otherwise we will wait up to .5 seconds in case
+ * the user reads some more.
+ */
+
+ /*
+ * It's unclear whether to use sk->mtu or sk->mss here. They differ only
+ * if the other end is offering a window smaller than the agreed on MSS
+ * (called sk->mtu here). In theory there's no connection between send
+ * and receive, and so no reason to think that they're going to send
+ * small packets. For the moment I'm using the hack of reducing the mss
+ * only on the send side, so I'm putting mtu here.
+ */
+
+ if (rspace > (sk->window - sk->bytes_rcv + sk->mtu))
+ {
+ /* Send an ack right now. */
tcp_read_wakeup(sk);
+ }
+ else
+ {
+ /* Force it to send an ack soon. */
+ int was_active = del_timer(&sk->retransmit_timer);
+ if (!was_active || jiffies+TCP_ACK_TIME < sk->timer.expires)
+ {
+ tcp_reset_xmit_timer(sk, TIME_WRITE, TCP_ACK_TIME);
+ }
+ else
+ add_timer(&sk->retransmit_timer);
}
}