EXPERT RESPONSE
You mentioned that the network is rated at 100 Mbps. But are you sure? Have you reliably measured the end-to-end bandwidth?
A single half-duplex 10 Mbps hub hidden in the path will limit the end-to-end performance accordingly.
Even assuming that you do have 100 Mbps end-to-end, you may have congestion caused by other traffic limiting the available bandwidth. Or you may have packet loss caused by any number of problems such as a duplex conflict or media errors.
Then there are the effects of TCP to be considered. TCP uses a slow start mechanism that means it accelerates to maximum transfer rate slowly. A 5 Mbps file probably may not be big enough to get there. And if there is loss, from whatever source, congestion avoidance mechanisms will keep slowing down the transfer rates.
See any number of good references on the effects of loss and distance on TCP such as by Matt Mathis (Internet2)
http://citeseer.nj.nec.com/mathis97macroscopic.html
or various PowerPoint presentations available on the Internet. One that is more related to your question is
http://www.cs.washington.edu/homes/cardwell/quals/quals-paper.ps
as it described the effects of the slow start.
If you assume "optimal conditions" you still need to specify the propagation delay between the end-hosts so that slow start can be factored in. Then you need to know your stack (Reno, Tahoe, Vegas, etc.)
The overhead from Layers 3 and less should limit 100 Mbps one-way transfers by at most 2.5%. Up to 97.5 Mbps should be available.
I would try to separate out any TCP effects to start with. Probably the easiest thing to do is look at your steady state by transferring much larger files (1 Gbps). Also, don't do tests with standard clients. Get data transfer testing tools or high performance data transfer clients like gridftp and/or use UDP-based transfer clients that are not subject to TCP effects.
If you are still seeing slow transfers, you need to look more closely at your network.
|
