lkml.org 
[lkml]   [1996]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Fix for SLOW PPP Bug
Date
	This patch appears to have to have fixed the problem.  I'd
recommend to those higher up (Linus, can you hear me?) to get this
into the later kernels. I can notice a considerable difference in
speed getting online to type this message :-)

- Jared

Christoph Lameter spewed:
>
> I have tried to isolate when this bug was introduced and found that
> 1.3.72 works fine but 1.3.73 has the problem. I noticed some ACK changes
> in net/ipv4/tcp.c and made some diffs to revert those changes.
>
> 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);
> }
> }
>
>
>



\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.089 / U:0.480 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site