Date: Thu, 22 Nov 2001 04:45:22 -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.0111220444380.78399-100000@ren.sasknow.com> In-Reply-To: <Pine.BSF.4.21.0111220342010.78399-100000@ren.sasknow.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
> >
>
>
--
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.0111220444380.78399-100000>