From owner-freebsd-net Thu Aug 30 17:17:49 2001 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id 3D87637B401 for ; Thu, 30 Aug 2001 17:17:33 -0700 (PDT) (envelope-from hansc@datamatrix.com) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [fec0::1:12]) by Awfulhak.org (8.11.5/8.11.5) with ESMTP id f7V0D2A74095 for ; Fri, 31 Aug 2001 01:13:02 +0100 (BST) (envelope-from hansc@datamatrix.com) Received: (from root@localhost) by hak.lan.Awfulhak.org (8.11.6/8.11.6) id f7V0CpN20651 for freebsd-net@freebsd.org; Fri, 31 Aug 2001 01:12:51 +0100 (BST) (envelope-from hansc@datamatrix.com) Date: Fri, 31 Aug 2001 01:12:51 +0100 (BST) From: hansc@datamatrix.com Message-Id: <200108310012.f7V0CpN20651@hak.lan.Awfulhak.org> To: freebsd-net@freebsd.org Subject: slow ftp transfers forward from hans christensen Mime-Version: 1.0 Content-Type: text/plain Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I have recently redefined a problem which has been plaguing me for close to a year now. I have several FBSD boxes at a site fed by a Sprint T1 (Site A). Each of these boxes is capable of ftp'ing to each other on the same subnet at speeds approaching the limits of the disk subsystem. In short, transfers on the LAN between FBSD boxen appear to be fine. In addition, I have enlisted the help of the folks at sprint to ftp in and out of these boxes with speeds approaching the limits of the T1 line - no problem there. It should be noted that the sprint guys have done their transfers from within sprint's network and are therefore NOT crossing their own network access points. Here is where it gets weird. If I ftp into one of my boxes at Site A across the WAN (in this case from a colocation facility) and put a large file onto my server in Site A, I get speeds of about 10KB/s. This may fluctuate from 4KB/s to 16KB/s, but it far below what one would normally see across a T1 line. Interestingly enough, sending ftp traffic out of Site A seems to move five to ten time faster - not perfect, but workable. Below are example of the same file transferred first out of Site A to the colocation facility, and then the same file just transferred, back into Site A. You will note the difference in speeds... This colocation facility is NOT on the same network as sprint and therefore DOES have to cross one of Sprint's network access points. Furthermore, to rule out the possibility that the colo facility is to blame, I ftp'ed from a linux box on yet another ISP's network. This linux box had the same type of performance problems. Slow puts to Site A and reasonable gets from Site A. I have seen this before as well, between boxes at the colocation facility and again across different class c subnets. Sprint claims that the problem lies with the MTU settings of the boxes at the "linux side" and the "colo side." This smells wrong to me, but I confess that I don't really know that it is wrong. I have looked in the FBSD bug reports for any indication of a similar problem and do not see any so far, but I have seen several questions on the mailing list archives. Most of these are dismissed as improper configuration of ethernet cards. I have tried these suggestions but found no relief. I ftp close to a GB of info every night into Site A and I need it to go faster than it has been going, but I'm stumped. Anybody got any clues for the clueless? Hans Christensen hansc@datamatrix.com Remote system type is UNIX. Using binary mode to transfer files. ftp> put jdk-1_2_2_006-win.exe local: jdk-1_2_2_006-win.exe remote: jdk-1_2_2_006-win.exe 227 Entering Passive Mode (************). 150 Opening BINARY mode data connection for jdk-1_2_2_006-win.exe 100% |*************************************************************************** ***************************| 298 KB 00:00 ETA 226 Transfer complete. 305152 bytes sent in 3.66 seconds (81.33 KB/s) ftp> get jdk-1_2_2_006-win.exe local: jdk-1_2_2_006-win.exe remote: jdk-1_2_2_006-win.exe 227 Entering Passive Mode (*************). 150 Opening BINARY mode data connection for jdk-1_2_2_006-win.exe (305152 bytes). 100% |*************************************************************************** ***************************| 298 KB 00:00 ETA 226 Transfer complete. 305152 bytes received in 25.77 seconds (11.56 KB/s) ftp> Here is a dmesg: Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.3-STABLE #0: Fri Jun 1 06:59:28 PDT 2001 Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (501.14-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Features=0x387f9ff real memory = 201261056 (196544K bytes) avail memory = 192282624 (187776K bytes) Preloaded elf kernel "kernel" at 0xc035e000. VESA: v2.0, 8192k memory, flags:0x0, mode table:0xc02fd882 (1000022) VESA: ATI MACH64 Pentium Pro MTRR support enabled md0: Malloc disk npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at 0.0 irq 11 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at 7.2 chip1: port 0x5000-0x500f at device 7.3 on pci0 fxp0: port 0xe400-0xe43f mem 0xeb000000-0xeb0fffff,0xeb202000-0xeb202fff irq 10 at device 9.0 on pci0 fxp0: Ethernet address 00:90:27:9a:47:1e inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: port 0xe800-0xe83f mem 0xeb100000-0xeb1fffff,0xeb200000-0xeb200fff irq 5 at device 10.0 on pci0 fxp1: Ethernet address 00:90:27:9a:47:10 inphy1: on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ahc0: port 0xec00-0xecff mem 0xeb201000-0xeb201fff irq 11 at device 12.0 on pci0 aic7880: Wide Channel A, SCSI Id=7, 16/255 SCBs fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: failed to get data. psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 IP packet filtering initialized, divert disabled, rule-based forwarding enabled, default to accept, logging disabled ad0: 9787MB [19885/16/63] at ata0-master UDMA33 ad2: 19546MB [39714/16/63] at ata1-master UDMA33 acd0: CD-RW at ata0-slave using PIO4 Waiting 5 seconds for SCSI devices to settle no devsw da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 105010MB (215061120 512 byte sectors: 255H 63S/T 13386C) (majdev=0 bootdev=0xa0200000) Mounting root from ufs:/dev/ad0s1 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message