1

We are currently performing tests over a wireless network and are having some issues trying to get the correct configuration of iperf3.

Our server side command line is as follows iperf3 -s -p 5101

Our client side is iperf3 -u -t 120 -b 150M -p 5101 -i 0.1

My expectation is that the client would attempt to send 150M across the wireless link; however, the link is only 100M and therefore the server would only receive 100M and the remainder of the packets would be dropped. However, what we see is that the sender reduces its bitrate down to the link availability with the sent bitrate fluctuating depending on the link quality.

Our questions 1) is this expected behaviour? 2) how do we prevent this behaviour? 3) is there something else going on outside of iPerf that could cause this?

Client side version is Ubuntu 16.04 compiled iPerf 3.7+ server side is Ubuntu 18.04 package manager version 3.1.3.

5
  • When the link doesn't even take up the load traggic is queued and slowed down. You'd see drops when the path in between the links congested.
    – Zac67
    Sep 18 '19 at 6:31
  • So this is essentially the wireless network interface blocking the send() function?
    – Lhh92
    Sep 18 '19 at 7:10
  • You are forgetting about protocol overhead of the data-link, IP, and transport protocols that reduce the available throughput to something less than the link bandwidth. Wi-Fi is also problematic in that only one device at a time can send, Wi-Fi management frames, and the devices must take turns, so effective throughput is often half or less than the link bandwidth.
    – Ron Maupin
    Sep 18 '19 at 11:09
  • 1
    @Lhh92 By socket API design, the UDP egress queue doesn't simply spill over when the egress interface can't take the traffic. When the queue is full the send() calls become blocking, yes.
    – Zac67
    Sep 18 '19 at 13:21
  • How is this not off topic, since it's about an application not functioning correctly? That's above OSI layer-4.
    – Jesse P.
    Sep 23 '19 at 0:27
0

The -u specifies UDP which is not aware of link speed, so the only reason that it would only send 100Mbps is because your interface might only support up to 100Mbps. (Do you have a 100Mbps interface connected to a 1Gbps interface on the wireless device?) If the fluctuations you see are all under 100Mbps it corroborates the fact that your interface might only be syncing at 100Mbps.

To answer your question, the expected behaviour is to transmit the full specified speed, with -u. Only if you omit it, will it use TCP and associated congestion control to saturate the link, assuming you are sending enough streams concurrently by using -P. (not -p)

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