iperf bandwidth and simultaneous connections

Posted on 2014-01-27
Last Modified: 2014-04-08
I am using iperf to simulate the bandwidth performance for the VoIP. I am trying to understand the correlation between bandwidth and the number of calls running simultaneously.

I have a MPLS connection between PC1 and PC2. PC1 has a 50mb connection and PC2 has a 1MB connection.

So I setup my iperf client (PC1) with bandwidth as 1mbps and 1 as the number of parallel client threads to run and I see packets dropped. Does it mean that I am having issue with my existing VoIP traffic? I also setup my mss as 218, which the VoIP packet with g711 codec with all the appropriate header.

Now when I increase the bandwidth, the number of packets dropped increased.

Can somebody help me understand this?

PS. I got my setup from
Question by:leblanc
  • 2
LVL 40

Accepted Solution

noci earned 333 total points
ID: 39814855
if you start pushing say 2Mbps data through a 1Mbps link then half of the data cannot be passed on.
So please explain what you mean with increase the bandwidth.. the bandwidth of the link (in that case less loss should be observed) or increase of data being sent...

It depends on the protocol what would happen.
- TCP will slow down to a pace of 1Mbps through flowcontrol.
- UDP will just loose packets that don't fit.

VOIP mainly consists of UDP packets, so they will get lost.

mss should not get fit to the data being sent but to the underlying transport.
f.e. over a pppoE link the mss should be a tad smaller because of the ppp overhead incurred with the traffic. Or broken up packets should be allowed.

By shortening the packet you also increase overhead. Any IP frame has 20 bytes for IP header + 20 bytes for (UDP/TCP). Other protocols then UDP/TCP (Think GRE, IPSEC,SCTP etc.) have differing header sizes.
If you shrink the MSS you also force more frames & frame headers, or fragmented frames which at least have a 20 byte IP header, for all remain headers and cause massive overhead in reaasembling the original frames @ the destination.
LVL 32

Assisted Solution

harbor235 earned 167 total points
ID: 39814988
Nothing to help with here, you are limited to ~1Mbps because the theoretical maximum throughput is the speed of the smallest link, 1Mbps. But also remember that the speed of the link does not take into account overhead such as TCP/UDP/IP header information as well as link framing such as Ethernet/Frame-Relay, etc ..... So with the smallest link size of 1Mbps you should not expect 1Mbps of application throughput, perhaps ~70-80% of theoretical maximum.

harbor235 ;}
LVL 40

Assisted Solution

noci earned 333 total points
ID: 39815045
And please check your units.

50mb (millibits) is not a lot where as 1MB (Should roughly be 8Mbps).
You most probably meant: 50Mbps vs. 1Mbps.

those are differences in the order of 9 resp. 1 magnitudes.

The only way to get a greater bandwidth is by reducing overhead. So frames as large as possible without fragmentation. The regular hardware imposed limit is 1514 bytes for ethernet frames. (14 of those are the ethernet header). And maybe you need to correct it slightly smaller to prevent fragmentation across pppoE links.
Here is a more detailed explanation:

Author Comment

ID: 39815224
Thanks for the inputs. I few corrections:
- The link on the other side is 3mbps and not 1 mbps. Sorry.
- I set my mss as 218 bytes because the g711 digitized voice is 160 bytes + 58 bytes (RTP/UDP/IP/Ethernet)
- From my understanding, the voice with g711 codec take around 87kbps. So if I set my bandwidth to 1mbps for 2 calls, I should not get any dropped packets. I am not sure I understand that.

PC1 and PC2 are connected to a MPLS cloud.

My output from iperf:
c:\iperf -s -u -mss 218 -b 2000000 -S 184 -P 2 -f k -i 10

[ ID] Interval                  Transfer     Bandwidth       Jitter         Lost/Total Datagrams
[1884]  0.0-10.0 sec   834 KBytes   683 Kbits/sec  6.309 ms 1047/ 1628 (64%)
[1884] 10.0-20.0 sec   825 KBytes   676 Kbits/sec  5.734 ms 1122/ 1697 (66%)
[1884] 20.0-30.0 sec   817 KBytes   669 Kbits/sec  8.987 ms 1137/ 1706 (67%)
[1884] 30.0-40.0 sec   800 KBytes   655 Kbits/sec  9.454 ms 1142/ 1699 (67%)
[1884] 40.0-50.0 sec   841 KBytes   689 Kbits/sec  6.093 ms 1112/ 1698 (65%)
[1884] 50.0-60.0 sec   851 KBytes   697 Kbits/sec  8.348 ms 1102/ 1695 (65%)
[1884]  0.0-60.4 sec  5003 KBytes   679 Kbits/sec  7.443 ms 6716/10201 (66%)

Featured Post

VMware Disaster Recovery and Data Protection

In this expert guide, you’ll learn about the components of a Modern Data Center. You will use cases for the value-added capabilities of Veeam®, including combining backup and replication for VMware disaster recovery and using replication for data center migration.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Skype is a P2P (Peer to Peer) instant messaging and VOIP (Voice over IP) service – as well as a whole lot more.
ADCs have gained traction within the last decade, largely due to increased demand for legacy load balancing appliances to handle more advanced application delivery requirements and improve application performance.
After creating this article (, I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
This video gives you a great overview about bandwidth monitoring with SNMP and WMI with our network monitoring solution PRTG Network Monitor ( If you're looking for how to monitor bandwidth using netflow or packet s…

822 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question