OK, dump appended. Please let me know if there is anything else I
can do. I got this output by doing:
% tcpdump >& tcpdump.log
This was on 2.1.76 (machine receiving data). The ftp host is
running SunOS.
This dump makes no sense, in your original report:
I get reasonable performance with TCP, sending from machines on the
LAN to machine A. However, most times when I send a large amount of
random data (say 10000 bytes) from a LAN machine to machine B, I get
TCP stalls. These stalls last for at least 15 minutes (I give up after
that).
And you dump shows (sans ARP packets etc. which I've edited out):
10:44:29.167467 130.155.194.32.ftp-data > jubemgee.atnf.CSIRO.AU.1030: S 2061632000:2061632000(0) win 4096 <mss 1460>
10:44:29.167646 jubemgee.atnf.CSIRO.AU.1030 > 130.155.194.32.ftp-data: S 3351443739:3351443739(0) ack 2061632001 win 32767 <mss 1460> (DF)
10:44:29.297544 130.155.194.32.ftp-data > jubemgee.atnf.CSIRO.AU.1030: . ack 1 win 4096
10:45:03.662022 jubemgee.atnf.CSIRO.AU.1030 > 130.155.194.32.ftp-data: F 1:1(0) ack 1 win 64240 (DF) [tos 0x8]
10:45:03.771359 130.155.194.32.ftp-data > jubemgee.atnf.CSIRO.AU.1030: . ack 2 win 4096
10:45:03.771532 jubemgee.atnf.CSIRO.AU.1030 > 130.155.194.32.ftp-data: R 3351443741:3351443741(0) win 0
Not even one byte was transferred. And this shows a lot of TCP bugs
which were present before pre90-3. Can I suggest you rerun your tests
in the following way:
1) Do it with either 2.0.x latest or pre90-3, these we believe to have
reasonably behaving TCP stacks.
2) When you trace the dumps, turn on tcpdump well before you do the
transfers and perhaps add some arguments such as:
tcpdump -i eth0 port 20
(port 20 is FTP data, /etc/services is your friend)
Then we can get down to buisness. From the dump you provided, there
is nothing to diagnose ;-)
Later,
David S. Miller
davem@dm.cobaltmicro.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu