[1266] in linux-net channel archive
Re: Asymmetric TCP/PPP performance (very poor receiving TCP)
daemon@ATHENA.MIT.EDU (Robert L Krawitz)
Fri Oct 27 20:24:24 1995
Date: Fri, 27 Oct 1995 10:07:26 -0400
From: Robert L Krawitz <rlk@tiac.net>
CC: linux-net@vger.rutgers.edu
In-reply-to: <XAA01288@sys3.pe1chl.ampr.org> (linux@pe1chl.ampr.org)
From: linux@pe1chl.ampr.org (Rob Janssen reading Linux mailinglist)
Date: Wed, 25 Oct 1995 23:16:36 +0100 (MET)
Yes, I have seen this. Linux sends too many ACKs, it should send the
second ACK only when the window increases from 0 (or maybe from a very
small value) when data is read.
The extra flow of ACKs is also very noticible on the (low speed) amateur
packet radio network :-(
While it didn't solve my problem performance-wise, the patch at the
bottom of this message (which I didn't have time to post last night
for somewhat complicated reasons) does get rid of the excess ACK's
without causing any other problem I could identify. It's not really
the ideal way to do it, but I think it's the right idea.
Whatever is going on is a problem at all serial line speeds from 115200
down to 19200. Receiving TCP data runs at about 40% of maximum line
speed, while sending it runs at very close to 100%. At 115200, the
FTP packets come in about 1/4 second apart, at 57600 about 1/2 second,
and at 19200 about 1.5 seconds.
RCS file: /src/repository/linux-1.3/net/ipv4/tcp.c,v
retrieving revision 1.1.1.14
diff -u -r1.1.1.14 tcp.c
--- tcp.c 1995/09/16 14:15:55 1.1.1.14
+++ tcp.c 1995/10/27 14:01:51
@@ -2040,6 +2040,9 @@
return;
}
+ if (sk->window > MAX_WINDOW/4)
+ return;
+
t1 =(struct tcphdr *)skb_put(buff,sizeof(struct tcphdr));
memcpy(t1,(void *) &sk->dummy_th, sizeof(*t1));
