I use iperf3.7 to measure the throughput of a system that is capable of around max 4 Gbps.
The iperf3 server is running on a Linux machine. I start the traffic with this command on the client side with the following flags, -R option to let the server send to the client: iperf3 -c 32.0.161.84 -u -l 1360 -b 550M -P 8 -w 16M -R -t 3000
Most of the times everything works as expected, I receive around 4 Gbps. But on some occasions, like 1-2 times of 10 iterations I receive lower throughput than expected. How much lower seem to be random, could be 2 Gbps or 3 or 3.5. When I get the low throughput scenario, it usually stays low for several minutes. Sometimes, after a couple of minutes it could recover by itself up to max speed and sometimes it stays low longer time. When I get this low throughput scenario, I can get a good throughput scenario if stopping the traffic and starting again and in this case the client side have received a new ip address as it’s dynamically assigned to the client on each iteration.
Looking at the printouts from sending server side it says it’s sending 8x550M and I have also checked with ifstat that also shows it sends 4400 Mbps.
Still receiving side receive lower speed.
Mirroring the ethernet card of the machine that the iperf client (sending side) is running on into wireshark shows there is a silent gap of 10.8 ms from time to time which can explain the received lower rate.
In this example with wireshark, the traffic is 4.4 Gbps and then suddenly, it seems to be a silence gap for 10.8 ms and we lose 4486 ip frames with 1360 bytes. That can explain why the traffic decrease to 3 Gbps for a while.
Does anybody know if why this happens and if it is a known problem potentially fixed in later versions, 3.8 or 3.9? Any additional flag could be useful to avoid this scenario? I have tried to run the server on a different Linux machine, but same problem occur, so I don’t think it’s a problem on the machine itself.
BR Niklas
We changed the logging technique to something called net-sniff and then we cannot see the gap anymore when the lower throughput happens. So the gap I referred to initially was no real gap, more likely a bug in the logging. So we consider iperf3 to work as it should and think the lower throughput is due to something in the network instead.
