David Bar-On

Can you try ruining these tests using PR #1654 code? The issues may be related, so it seems to be worth testing whether the PR also fix this issue. (I...

Thanks for testing. The second test failed because the termination happened before all threads where created. I enhanced PR #1654 to also handle this case. **Can you check if the...

The exception happens in iperf_api.c/iperf_parse_arguments(): ```c test->settings->gso_dg_size = blksize; /* use the multiple of datagram size for the best efficiency. */ test->settings->gso_bf_size = (test->settings->gso_bf_size / test->settings->gso_dg_size) * test->settings->gso_dg_size; ``` The...

@noamsto, please re-run the test with the following options and let us know the results: 1. Server verbose and debug (`-d -V`) option to see the size of the send/receive...

Hi @noamsto, this is interesting. It is expected that throughput will decrease when message size is decreased. Therefore, it is not clear what iperf2 is doing to keep the same...

One more thing to try (in addition to the window-size and Wireshark above), is **iperf3 burst**. See issue #899. Sending packets in burst have less ipref3 internal overhead, so this...

@noamsto, thanks for the input. As none of the options I suggested help, maybe the issue is related to CPU usage by iperf3. Can you run both client and server...

> Maybe Iperf3 is not generating enough work for the CPUs when the message size is small? I agree that somehow this is the case. The following two tests may...

Hi @rsevilla87, very good and useful analysis! I tried your suggested change on my computer, and indeed the throughput is increased dramatically (in my case from 70Mbps to 93Mbps). From...

I believe I found the root cause for the iperf3 low performance with small messages sizes. While iperf3 use the same send and receive messages sizes, **iperf2 has different messages...