I've been experiencing an extreme loss of performance with some
TCP connections, most easily reproducible being ftp sessions. I've done a fair
bit of testing with this and have been unable to find the source of the issue.
I have a (from here) reproducible example of the problem. Any help anyone could
give digging up the root of the problem would be most appreciated. AFAICT
this is not a configuration problem.
My local net looks like the following:
(linux i386 box 2.2.14)--------+
|
(linux i386 box 2.2.5)-------10bt hub-------ascend pipeline 50---- ISDN to ISP
|
(linux axp box 2.2.10)-------------+
|
(windows i386 win98)---------------+
Typical download speeds should be ~15kBps, assuming the rest of the
Internet plays nicely. I noticed while trying to ftp Wine source that
my xfers were going at ~1.5kBps, no matter which wine mirror I used. This
problem never occurred on my recently decommissioned ultra 5. Also the win98
box has no troubles, downloading at the expected 15kBps rate. Web download
speeds are also very slow sometimes, which is why I suspect a generic TCP
issue rather than specifically FTP, though half the time they are just
as fast as they ought to be.
Here are the first few lines of tcpdump output. I have placed
a larger, more verbose output of tcpdump -vvx src or dst ursula.gmcl.com at
http://hcafe.com/~tex/ftp_dump.txt. The output shown here is the output
generated from doing ncftp ftp://ftp.winehq.com/pub/wine/wine-precrash.tar.gz.
I've also put output of
I've chopped the first few syn/ack lines for clarity.
It looks as if peace (my box) is not acking about 2/3 of the packets
sent. I'm not Mr. TCP guru, so I'm not sure why that might be (or maybe I'm
not reading the output correctly). The packets do appear to be complete, and
show up with the -x option to tcpdump. Eventually transfers time out and
(nc)ftp aborts.
tex@peace:/home/tex# tcpdump -vv src or dst port ftp-data
User level filter, protocol ALL, datagram packet socket
tcpdump: listening on eth0
<negotiation snipped here to save space>
18:09:54.697437 ursula.gmcl.com.ftp-data > peace.off.org.2265: P 1:1449(1448) ack 1 win 32120 <nop,nop,timestamp 87961911 9390341> (DF) [tos 0x8] (ttl 44, id 63700)
18:09:54.697469 peace.off.org.2265 > ursula.gmcl.com.ftp-data: . 1:1(0) ack 1449 win 31856 <nop,nop,timestamp 9390366 87961911> (DF) (ttl 64, id 59845)
18:09:54.793473 ursula.gmcl.com.ftp-data > peace.off.org.2265: P 1449:2897(1448) ack 1 win 32120 <eol> (DF) [tos 0x8] (ttl 44, id 63701)
18:09:54.941668 ursula.gmcl.com.ftp-data > peace.off.org.2265: P 2897:4345(1448) ack 1 win 32120 <nop,nop,timestamp 87961936 9390366> (DF) [tos 0x8] (ttl 44, id 63702)
18:09:54.941712 peace.off.org.2265 > ursula.gmcl.com.ftp-data: . 1:1(0) ack 1449 win 31856 <nop,nop,timestamp 9390390 87961911,nop,nop, sack 1 {2897:4345} > (DF) (ttl 64, id 59846)
18:09:55.038139 ursula.gmcl.com.ftp-data > peace.off.org.2265: P 4345:5793(1448) ack 1 win 32120 <eol> (DF) [tos 0x8] (ttl 44, id 63703)
18:09:55.190097 ursula.gmcl.com.ftp-data > peace.off.org.2265: P 5793:7241(1448) ack 1 win 32120 <nop,nop,timestamp 87961960 9390390> (DF) [tos 0x8] (ttl 44, id 63704)
18:09:55.190142 peace.off.org.2265 > ursula.gmcl.com.ftp-data: . 1:1(0) ack 1449 win 31856 <nop,nop,timestamp 9390415 87961911,nop,nop, sack 2 {5793:7241}{2897:4345} > (DF) (ttl 64, id 59847)
Here is the output of ifconfig eth0. Notice the lack of errors as
well as the existence of collisions, indicating the interface is in half duplex
mode. Also local xfers seem to work reasonably close to ether line speed.
The mac layer data from tcpdump -e (not included here) seems to be OK, or
at least source and destination addresses are accurate.
eth0 Link encap:Ethernet HWaddr 00:48:54:62:C4:1C
inet addr:206.163.206.2 Bcast:206.163.206.7 Mask:255.255.255.248
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:68527 errors:0 dropped:0 overruns:0 frame:0
TX packets:58665 errors:0 dropped:0 overruns:0 carrier:0
collisions:824 txqueuelen:100
Interrupt:14 Base address:0x7800
I had originally thought this to be a problem with the intel eepro100
driver, but after trying a different ether card with the same results
(Realtek 8139) and discovering it to be a problem with all linux boxes
(and only linux boxes) I figured out that wasn't the problem.
The kernels I've built were all built with gcc-2.9x, though I
doubt this is the problem since it occurred with the original kernel
shipped with my Suse 6.3 distribution.
Thanks again for any help/suggestions you might have. If any further
debugging data would be of use please let me know.
Austin
-
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/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:18 EST