JSON output missing receiver bandwidth for UDP

[michaelfranzl]

Using latest version, with UDP testing, sending bandwidth is always 1Mbits/sec. Running iperf3 -u gives lower bandwidth for receiver, which makes sense given packet loss:

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.00  sec  1.25 MBytes  1.05 Mbits/sec  0.000 ms  0/918 (0%)  sender
[  4]   0.00-10.08  sec   820 KBytes   667 Kbits/sec  22.755 ms  323/911 (35%)  receiver

However, the JSON output of iperf3 -u -J is apparently missing the bandwidth on the receiver. "bits_per_second" is the usual 1Mbit/sec of the sender:

...
"sum":  {
                        "start":        0,
                        "end":  10.325652122497559,
                        "seconds":      10.325652122497559,
                        "bytes":        1310904,
                        "bits_per_second":      1048716.9241566667,
                        "jitter_ms":    17.814066799414466,
                        "lost_packets": 294,
                        "packets":      918,
                        "lost_percent": 32.026143790849673
                },
...

The TCP reports have the JSON keys "sum_sent" and "sum_received", however UDP reports only have "sum".

Is there any way to calculate the UDP receiver's bandwidth from the data provided in the JSON?

[bmah888]

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.)

[gourabm1981]

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 ?

[AStotal]

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

Maybe there is some workaround?

[bmah888]

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.

[awardblvr]

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

[bmah888]

@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.

[awardblvr]

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 ***@***.***> 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 <#584 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFE_e3JCfwSxfr_negMTgZCq8Z6xIkdlks5uapAegaJpZM4NgILa> .

[hakujin22]

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 %

[davidBar-On]

@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 (router) 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 only include non-zero data from the receiver. E.g. client will set it when -R or bidirectional are used, but will set zero when it is 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 you approve this may be a usable approach I will try to implement it.