Skip site navigation (1)Skip section navigation (2)
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>