Date: Thu, 22 Nov 2001 21:39:36 +0100 From: "Roger 'Rocky' Vetterberg" <listsub@rambo.simx.org> To: Ryan Thompson <ryan@sasknow.com> Cc: francisv@dagupan.com, freebsd-questions@FreeBSD.ORG Subject: Re: Maximizing throughput Message-ID: <3BFD6288.3010500@rambo.simx.org> References: <Pine.BSF.4.21.0111220444380.78399-100000@ren.sasknow.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Just to give you some figures to compare with: time ncftpget -u rocky\ ftp://rambo/4.4-disc3.iso Password: ******** 4.4-disc3.iso: 627.88 MB 5.50 MB/s real 1m58.424s user 0m1.066s sys 0m51.974s This would give a troughput about 40-45Mbps, which sounds about right since this is a fairly busy 100Mbit network. Both machines armed with Netgears F310-TX cards connected to a Netgear 10/100 switch, high quality cable all the way. -- R Ryan Thompson wrote: > Ryan Thompson wrote to francisv@dagupan.com: > > >>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, >> > ^^^ > UDP, I should say. Actually, the difference in performance isn't > significant. > > > >>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 >>> >>> >> > 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?3BFD6288.3010500>