high packet loss with UDP test 10G Domestic

[vangvc]

Hi ipert Team,
We are facing high packet loss when testing 10G using the following command:
iperf3.exe -p 5201 -c [IPaddress server] -B [IPaddress Client] -u -b 2000m -t 60 -R
iperf3.exe version 3.19.1
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-60.01 sec 12.9 GBytes 1.85 Gbits/sec 0.000 ms 0/9514987 (0%) sender
[ 5] 0.00-60.00 sec 11.2 GBytes 1.61 Gbits/sec 0.007 ms 1247650/9514406 (13%) receiver

[vangvc]

Pls help me

[davidBar-On]

UDP is not a connection-oriented protocol like TCP, meaning that sender have no feedback about whether packets were received by the receiver, whether packets were lost, etc. Therefore, UDP packets can be sent in any rate, regardless of the network interface throughput, etc.

In your case the sender, the iperf3 Server per the -R option, is sending about 2Gbits/sec as requested. (Not sure why it is only 1.85 Gbits/sec, maybe this is the maximum performance of the Server's computer.) However, either the network does not support the 1.85Gbits/sec, the receiver (client) computer resources does not support it, there is other traffic on the network, etc. Therefore, some of the UDP packets are lost.

To see what is the expected maximum rate, run this test using TCP. Note that the packet/message size is important, so make sure to run the UDP and the TCP tests using the same length, set by the -l option. (You can determine the default length used by the UDP test by using the -V option.)

[vangvc]

Dear Team, Option -w??? Frequently this (lossy or slow UDP tests) can be the result of using the socket buffer size. Try using the -w option to set a large socket buffer size. Vào Th 4, 12 thg 11, 2025 lúc 18:55 David Bar-On ***@***.***> đã viết:

…

*davidBar-On* left a comment (esnet/iperf#1963) <#1963 (comment)> UDP is *not* a connection-oriented protocol like TCP, meaning that sender have no feedback about whether packets were received by the receiver, whether packets were lost, etc. Therefore, UDP packets can be sent in any rate, regardless of the network interface throughput, etc. In your case the sender, the iperf3 Server per the -R option, is sending about 2Gbits/sec as requested. (Not sure why it is only 1.85 Gbits/sec, maybe this is the maximum performance of the Server's computer.) However, either the network does not support the 1.85Gbits/sec, the receiver (client) computer resources does not support it, there is other traffic on the network, etc. Therefore, some of the UDP packets are lost. To see what is the expected maximum rate, run this test using TCP. Note that the packet/message size is important, so make sure to run the UDP and the TCP tests using the same length, set by the -l option. (You can determine the default length used by the UDP test by using the -V option.) — Reply to this email directly, view it on GitHub <#1963 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUO4USDAG57WEP6RKWIWCS334MN4BAVCNFSM6AAAAACLYHTTFCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKMRRGU3DANJQGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[bmah888]

-w can often be helpful with reducing loss during UDP tests. Maybe try -w 32k (32KB) and work your way upwards, say by doubling.

As per previous suggestion, maybe try doing a TCP test first to see what reasonable data transfer speeds you can expect.

Note that iperf3 isn't officially supported on Windows.