I recently got around to measuring effective throughputs on a pretty big, switched network. I measured the throughputs by having two laptops, both running Iperf; one being the server, the other a client. I made sure to measure both the up- and downlink throughputs. My problem comes from the fact that some 100 Mbit/s paths were measured as everything from 50 to 80 Mbit/s. That seems kind of low, even taking overhead and plenty of active users into account.

Some useful information:

The network uses RSTP and has no routed hops. There are at least 100 active users along the path from the Iperf client to the server. The throughputs were measured on paths with at least three 100 Mbit/s switches between the two laptops. I measured using TCP.

So my question can be summarized as: are these values something to be expected

Another question: I also got about 250-300 Mbit/s on a Gigabit switch while having the two nodes plugged into it. I used regular straight-through cables for both nodes. This can't be expected, even though the switch is in use by other machines, right?

  • 2
    Switched networks are almost invariably all wire-speed, excluding microbursting. I would suspect your measurement kit may not scale to required rates. Also network should always be measured with UDP, TCP tends to measure hosts TCP stack implementation. – ytti Sep 6 '13 at 12:06
  • @ytti, I would say your response is true, as long as you confine the hosts to one TCP socket each. If you use iperf to open five parallel TCP sockets between the same hosts, you will saturate the link as long as the host isn't limited by the CPU or PCI bus – Mike Pennington Sep 6 '13 at 12:18
  • Thanks for the reply! Both laptops have Gigabit network interfaces, and Iperf supports well-over 100 Mbit/s. I measured using TCP because that's what most users will be using, so I'm not really interested in the absolutely highest throughput possible, but rather what an average user can expect. Does that make sense? – Dave Sep 6 '13 at 12:22
  • @Dave, If your goal is to quantify the average user experience, you just made these measurements very situational and application dependant... iperf wont measure that – Mike Pennington Sep 6 '13 at 12:28
  • It's indeed very situational, but each individual measurement isn't as important as comparing several of them to each other. Iperf will measure the highest throughput on a given path using TCP, right? – Dave Sep 6 '13 at 12:31

With throughput defined as the amount of data transferred from point A to point B in a period of time. The significant variables in throughput are: Latency, Packet Size, and Retransmissions (quality). This was proven with the Mathis Equation.


TCP Basics: TCP connections establish a session with a SYN, the receiving machine sends and ACK, Then data flows. When the window (setting in windows saying how much data to collect before it asks for validation/acknowledgement of receipt) fills up another set of acknowledgements are sent to start the next flow of data.

If your environment has the default MTU of 1500, and you introduce a device that has an MTU of 1460, this will slow down your network because all packets flowing through the device will be fragmented; when the 1500 packet hits the device with MTU of 1460 it will fragment the packet into two packets and transmit it.

If you have Jumbo frames enabled and your MTU is 9220 you will get much higher throughput, 5 times higher. Each payload is larger even though the packet has the same latency.

In short: Throughput is conditional and depended on both host and network device settings. Use the Mathis Equation as a guide for what you could expect with the given data points for your network. Validate your findings and verify units; Megabit/sec and Megabyte or Kilobit and Kilobyte are not the same.


Test with UDP to get an accurate throughput measurement. Also, you'll need to increase the UDP send rate above the default to get a good measurement. With TCP, you'll be dealing with windowing which will give you an artificially low number for your purposes. I typically try to send UDP above the known link speed. You'll then see your send rate as X and your actual throughput as some number less than X.


You can turn off TCP windowing with iperf using the -N option for "tcp no-delay". As per the documentation "set TCP no delay, disabling Nagle's Algorithm"

I would highly recommend using this option with concurrent TCP sessions to simulate something closer to ACTUAL network traffic rather than shooting a UDP blast.

  • This reads more as a long comment and not an answer. If I convert it to a comment, it is too long and will be truncated. Could you please edit to make this an answer or remove it and add your comments where they are appropriate (requires 50 reputation)? – YLearn Nov 13 '13 at 18:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.