Messages in this thread | | | Date | Wed, 15 Mar 2000 18:39:30 -0800 | From | Austin Schutz <> | Subject | Odd TCP problems with 2.2.x |
| |
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/
| |