Speed Testing and Throughput testing
oberman at es.net
Sat Nov 7 17:56:36 CST 2009
> Date: Mon, 2 Nov 2009 18:22:19 -0500
> From: Jon Meek <meekjt at gmail.com>
> I use iperf with packet capture on both sides, then analyze the packet
> capture for per-second throughput and re-transmits. I usually do 10
> TCP streams for 30 seconds.
> Note that on GigE with significant RTTs (5-15 ms) some TCP tuning is
> needed to deal with the bandwidth delay product. It is also possible
> that Ethernet drivers will have an effect. Local testing of the pair
> of test machines should be done if you can't get to about 980 Mbps on
> a Gig link (keeping in mind the comment about TCP tuning as latency
> On Mon, Nov 2, 2009 at 4:56 PM, Mark Urbach <mark.urbach at pnpt.com> wrote:
> > Anyone have a good solution to get "accurate" speed results when testing at 10/100/1000 Ethernet speeds?
> > Do you have a server/software that customer can test too?
I'll also suggest http://fasterdata.es.net as a resource for network
tuning. Tuning TCP is hard. UDP is simple, but some things can even
Many less than obvious things can have a huge impact on high-speed data
transfer. The choice of congestion algorithms can be very
significant. As anyone who has used bittorrent should have noticed,
having multiple TCP streams works better than a single stream.
An oddity we have noted is that some routers will process switch layer
2 traffic if a layer 3 interface exists on the port even if it is
unconfigured and unused. Man, that kills performance, even in low
FWIW, we use mostly iperf, but may be biased as the iperf maintainer
works here. We did start using iperf before we hired him, though.
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
More information about the NANOG