Open O-ring opened 4 years ago
What seems to be happening is that UDP packets are getting received out-of-order. You can see that in the summary statistics. iperf3 was designed to handle this, but there seems to be some kind of pathological condition that causes negative counts. We're attempting to count packet losses by finding gaps in sequence numbers. The problem happens when misordered packets show up to fill those gaps we try to compensate by decrementing the loss count, and something is happening that we don't handle correctly.
I think there's another issue open for this type of problem already, if there is I might close this one and point to the already-existing one instead.
Er actually another possible explanation came up in the discussion for #914, which is that UDP packets (whether in order or misordered) can be sent in one measurement interval and received in a subsequent interval. In the first program output privded, all of the "packet lost" values per interval, added together, equal 0, which is the total number of packets lost in the summary.
If this is the case, then iperf3 is working, albeit in a somewhat clunky fashion.
Hello Bruce,
thanks for the explanation. Indeed the following sum:
2622+573-1919+698-1465-165-344 equal to zero.
Question: about the wrong receiver speed reported. Any idea why iperf is reporting a bogus receiver value? The sender is firing UDP datagrams at 800Mbit/s while the receiver is reporting >1Gbit/s. Thanks again for the feedback.
@O-ring, it seems that somehow the UDP packets are duplicated in your system. Note that the packets count is about 69K per second, but that in both cases high number of packets were received out of order (36K packets/sec in the first case and 72K packets/sec in the second case). The extra bandwidth see to come from these out of order packets.
The bytes and packets count are done in iperf_udp_recv(). While each byte received is counted, the number of packets received is determined by the highest packet number received. Therefore, if UDP packets are received more then once (e.g. because they are duplicated by the system), number of bytes received counting will be affected, but number of packets counting will not be affected. The extra (duplicated) packets are counted as out of order packets.
Version of iperf3: 3.9
Hardware: intel x86_64
Operating system (and distribution, if any): slackware 14.2
Bug Report
I'm getting these crazy output when I run iperf3.9 udp traffic and reverse mode (-R) 10.24.209.252 host is running on a 10Gbit/s NIC, while the 10.68.64.37 is running on a 1Gbit/s NIC
Edit: Reformatted program output for legibility. --bmah.