Date: Thu, 22 Nov 2001 04:38:25 -0600 (CST) From: Ryan Thompson <ryan@sasknow.com> To: francisv@dagupan.com Cc: freebsd-questions@FreeBSD.ORG Subject: RE: Maximizing throughput Message-ID: <Pine.BSF.4.21.0111220342010.78399-100000@ren.sasknow.com> In-Reply-To: <10F29E27A956D511B0940050DA8D86A9340BE9@apmail.dagupan.com>
next in thread | previous in thread | raw e-mail | index | archive | help
francisv@dagupan.com wrote to ryan@sasknow.com: > Thank you, Ryan, for the detailed response. Please see my comments below: > > [ Large snip ] > > > My first wave of questions goes something like this, > > 1. What application layer protocol is being used to transfer? > > FTP Right. Application layer protocols are ALWAYS bad tests of link throughput. There is a lot of overhead, and the application itself might leave the link idle. > > 2. Does it run over TCP or UDP? > > TCP Yep.. Slowstart might be a factor, if there are more than a few retransmissions. You might be running into flow control problems on the receiver side. FTP and TCP also add quite a bit of overhead, so a better test would be to set up some count firewall rules on one of the machines to monitor ALL traffic on the link. Probably your transmission is humming along fine most of the time. Every time one end has to retransmit, though, your transmission rate essentially gets cut in half. And TCP WILL have to retransmit at semi-regular intervals, because it always probes the link to find the maximum rate, and will invariably exceed the maximum and cause a packet to be lost. So, I guess, what I'm saying here, is that this is fairly normal. There are many good reasons WHY TCP operates like this... And there are many good reasons why you should not mess with the way TCP operates ;-) > > 3. Are you using CAT5 cabling between both hosts and the switch? > > Yes, we're using category 5 UTP cable on both hosts; less than 5 feet > per host to the switch Assuming the cable tests ok, is not damaged, or bent at sharp angles, that should be OK. > 4. How loaded are the machines? The switch? > > Between 5-10 percent load Depending on what you mean by that (CPU load? Network load? Disk load? Some combination of those three?), that doesn't sound like a major factor. > > 5. How did you calculate your "speed" statistic? Are you sure? > > I don't know if the throughput display (after uploading) of the > FTP client is in megabytes or megabits; I'm guessing it's in > megabytes, not megabits. From my MRTG graph, it used a maximum of > 15.6 megabits -- is this the actual throughput limit? ftp(1) reports transfer times in KB/s (kilobytes per second). The derived conversion from KB/s -> Mbps (megabits per second) is x KB/s = 8x/1024 Mbps = x/128 Mbps 15.6 Mbps is not special in any way that I'm aware of, at least not in your context. Typical application layer throughput on Fast Ethernet is usually on the order of, say, 70 Mbps, but is quite variable, so 60-80 Mbps isn't unusual, depending on the application. 15.6 Mbps is kind of slow. Chances are the actual link is going much faster, but you are running into retransmissions. (Watch the FTP progress.. does it pause briefly during the transfer? The answer is probably YES, unless you are pretty lucky). I just ran a test between a FreeBSD 4.4 (TCP extensions enabled) machine and a 3.5 machine, over our 100Mbps switched Ethernet LAN (which is under some load), using a ~630MB file. Running three trials, I got about 2MB/s each time (~16Mb/s). And, actually, that's not too bad for FTP, considering the load this LAN, and the end hosts, are already under. Different implementations of TCP will also vary somewhat, in the way they handle retransmissions. The same file, copied with NFS over TCP between the same two hosts, took (wall time) about 6 minutes (about 16MB/s), so the results are similar. So, in your case, I'd say you're within 100% of normal for a single TCP connection. - Ryan > > 6. Are there any routers between the two hosts? > > No, there are no routers in between > > Things to try: > Connect the machines directly with crossover cable, or connect them to > a hub. Run tcpdump on one of the machines (or another host on the same > segment) and look for any weirdness. > > As for possible causes/remedies, it's hard to say at this point. Like > I said, one of your likely symptoms is dropped packets. This could > happen at just about any layer. Maybe your cabling is poor grade (or > there is too much EMI), causing Ethernet frames to get dropped. Maybe > one of the hosts (or the switch) is configured wrong. Maybe your > transfer application is broken. Maybe one of your network cards needs > to be replaced. Maybe one of your cables is defective. > > So, as for increasing the bandwidth limit, you'll need to fix whatever > is slowing things down. :-) > > Hope this helps, > - Ryan > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message > -- Ryan Thompson <ryan@sasknow.com> Network Administrator, Accounts SaskNow Technologies - http://www.sasknow.com #106-380 3120 8th St E - Saskatoon, SK - S7H 0W2 Tel: 306-664-3600 Fax: 306-664-1161 Saskatoon Toll-Free: 877-727-5669 (877-SASKNOW) North America To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0111220342010.78399-100000>