Iperf: JSON output missing receiver bandwidth for UDP

Right. This is a very old bug, one that might have been present in iperf3 from the beginning. I sort of realized it (why didn't I file an issue for it?) when I was doing the work on #562. As you correctly pointed out, UDP tests don't break out the client-side and receiver-side statistics separately. I'm not sure if what's reported is the client, sender, or a mish-mash of the two. It's also not clear to me why TCP is different.

It'd be a good thing if UDP tests could emit statistics output that's more like TCP in this respect (both sender and receiver side separately), although I'm not sure how to maintain some kind of compatibility with programs that consume the existing JSON output. (In #562, I fixed the human-readable output for UDP, which you presented in your first output snippet...I was less worried about backward compatibility in that case because programs shouldn't be trying to read that output anyway.)

Is there any resolution done to this problem for UDP JSON output ? We are trying to parse out the JSON output but not sure what is what . A example JSON output is :-

    }],
            "sum":  {
                    "start":        0,
                    "end":  10.004644870758057,
                    "seconds":      10.004644870758057,
                    **"bytes":        4364528380,**
                    "bits_per_second":      3484585580.8672519,
                    "jitter_ms":    2.3222640079292773,
                    "lost_packets": 2102766,
                    "packets":      2989403,
                    "lost_percent": 70.34066668160834
            },

but we are not sure what is this bytes thing , is it sent bytes or the received bytes ?

When it will be fixed? I need to get receiver's bps from JSON output.

Maybe there is some workaround?

It's not on the roadmap right now. Fixing this actually requires a change to the state machine and protocol between the client and server.

May I ask... If testing with UDP and I parse the json from the client side and get

end.sum.bits_per_second     AND 
end.sum.lost_packets

Will I have a fair representation as to whether the transmission is sending and receiving data from the server side? What would I have to do to verify both directions os send/receive was successful? Parse the text output from:

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.00  sec  1.26 MBytes  1.06 Mbits/sec  0.000 ms  0/81 (0%)  sender
[  5]   0.00-10.00  sec  1.26 MBytes  1.06 Mbits/sec  0.052 ms  0/81 (0%)  receiver

@awardblvr : It depends I guess on how you define "successful". I suppose one measure might be that if end.sum.lost_packets is zero, then the receiver didn't detect any lost packets. There are some edge cases around this however, mostly having to do with what happens to packets that are still in flight when the client declares the test completed.

Thanks..., I only want to know that I can read this ONE json output and see
BASICALLY that the packets transferred from server-->client and the packets
transmitted from client-->server arrived and that there were no lost
packets on either the client-received packets:

I believe that is:

end.sum.packets .
end.sum.lost_packets
end.sum_receiver.packets <--- NEW with PATCH
end.sum_receiver.lost_packets <--- NEW with PATCH

Please correct me if I am wrong!

"end": {
"sum": {
"end": 10.00,
"seconds": 10.00,
"bits_per_second": 1058280.26,
"bytes": 1322892,
"packets": 81,
"start": 0,
"jitter_ms": 0.056,
"lost_packets": 0,
"lost_percent": 0
},
"streams": [
{
"udp": {
"end": 10.00,
"socket": 5,
"seconds": 10.00,
"bits_per_second": 1058280.26,
"bytes": 1322892,
"packets": 81,
"out_of_order": 0,
"start": 0,
"jitter_ms": 0.056,
"lost_packets": 0,
"lost_percent": 0
}
}
],
"sum_sender": { <--- NEW with PATCH
"end": 10.00,
"seconds": 10.00,
"bits_per_second": 1058280.26,
"bytes": 1322892,
"packets": 81,
"start": 0,
"jitter_ms": 0,
"lost_packets": 0,
"lost_percent": 0
},
"sum_receiver": { <--- NEW with PATCH
"end": 10.00,
"seconds": 10.00,
"bits_per_second": 1058271.16,
"bytes": 1322892,
"packets": 81,
"start": 0,
"jitter_ms": 0.0568,
"lost_packets": 0,
"lost_percent": 0
}

Thanks

-A

On Thu, Sep 13, 2018 at 10:04 AM Bruce A. Mah notifications@github.com
wrote:

@awardblvr https://github.com/awardblvr : It depends I guess on how you
define "successful". I suppose one measure might be that if
end.sum.lost_packets is zero, then the receiver didn't detect any lost
packets. There are some edge cases around this however, mostly having to do
with what happens to packets that are still in flight when the client
declares the test completed.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/esnet/iperf/issues/584#issuecomment-421079759, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFE_e3JCfwSxfr_negMTgZCq8Z6xIkdlks5uapAegaJpZM4NgILa
.

Encountered a similar issue with the lack of independent Tx/Rx B/Ws for UDP.
Took a different approach.

I calculated RxMbps using the TxRate and Drop %.

TxMbps = result.Mbps
RxMbps = TxMbps - (TxMbps * (result.lost_percent / 100))

Server --- 10Mbps ---SRX(Router) ---5Mbps -----Client
(Traffic shapers applied on the SRX Interfaces)

I test both directions @ 20Mbps.

iPerf3 UDP Upload:

Remote: 10.8.8.100
Local: 10.9.9.222
Protocol/Port: UDP / 33333
Start Time: Sun, 10 Jan 2021 03:51:23 GMT
Duration (sec): 10
Transmit Rate: 20.0Mbps
Receive Rate: 9.58Mbps
Jitter: 0.7 ms
Lost Packets: 8990
Lost Percentage: 52.07 %
Local CPU: 9.03 %
Remote CPU: 0.76 %

iPerf3 UDP Download:

Remote: 10.8.8.100
Local: 10.9.9.222
Protocol/Port: UDP / 33333
Start Time: Sun, 10 Jan 2021 03:51:38 GMT
Duration (sec): 10
Transmit Rate: 20.0Mbps
Receive Rate: 4.82Mbps
Jitter: 0.49 ms
Lost Packets: 13172
Lost Percentage: 75.9 %
Local CPU: 2.5 %
Remote CPU: 8.26 %

@hakujin22, "_RxMbps = TxMbps - (TxMbps * (result.lost_percent / 100))_" will probably not work in general. This is because the data is gathered only locally and not also from the remote end. E.g. in the data you sent, the server to client end to end link bandwidth is 5Mbps. However, assuming the Upload is server to client, you got 10Mbps on the server. This is because this is the measure of the server to SRX throughput and not end to end.

@bmah888, since the server data can be received using the --server-output, the following approach may be used as a solution/workaround for UDP JSON summary statistics issue:

1. "_sum_received_" and "_sum_sent_" JSON sections will be added to the UDP _end_ summary on both server and client. These section will not replace the _sum_ section.
2. The "_sum_received_" will include non-zero data only from a receiver. E.g. client will set it when -R or bidirectional are used, but will set zero when only a sender.
3. "_sum_sent_" will be set using similar rules, but for sender or bidirectional.

This approach seem to be backward compatible with current solution. If yo approve this may be a usable approach I will try to implement it.