Iperf: JSON输出缺少UDP的接收器带宽

正确的。 这是一个非常古老的错误，可能从一开始就存在于iperf3中。 当我在＃562上进行工作时，我有点意识到了（为什么我没有为此提问题？）。 正如您正确指出的那样，UDP测试不会单独列出客户端和接收方的统计信息。 我不确定报告的是客户端，发件人，还是两者的混搭。 我也不清楚TCP为什么与众不同。

如果UDP测试可以发出更像TCP的统计信息输出（在发送方和接收方这两个方面），这是一件好事，尽管我不确定如何与使用现有JSON的程序保持某种兼容性。输出。 （在＃562中，我修复了您在第一个输出代码段中呈现的UDP可读输出……在这种情况下，我不太担心向后兼容性，因为程序无论如何都不应该尝试读取该输出。）

对于UDP JSON输出，该问题是否已解决？ 我们正在尝试解析JSON输出，但不确定是什么。 JSON输出示例为：-

    }],
            "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
            },

但是我们不确定这是什么字节，是发送字节还是接收字节？

什么时候会修复？ 我需要从JSON输出中获取接收者的bps。

也许有一些解决方法？

它现在不在路线图上。 解决此问题实际上需要更改客户端和服务器之间的状态机和协议。

请问...如果使用UDP进行测试，并且我从客户端解析json并获取

end.sum.bits_per_second     AND 
end.sum.lost_packets

关于传输是否正在从服务器端发送和接收数据，我是否有一个公平的表述？ 如何验证发送和接收的两个方向均成功？ 解析以下文本输出：

- - - - - - - - - - - - - - - - - - - - - - - - -
[ 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 ：这取决于您如何定义“成功”。 我想一种措施可能是，如果end.sum.lost_packets为零，则接收方没有检测到任何丢失的数据包。 但是，有一些边缘情况，这主要与客户端声明测试已完成时仍在传输中的数据包发生了什么有关。

谢谢...，我只想知道我可以阅读这一个json输出并看到
基本上是从服务器->客户端传输的数据包和数据包
从客户端传输->服务器到达并且没有丢失
客户端接收的数据包上的数据包：

我相信是：

end.sum.packets。
end.sum.lost_packets
end.sum_receiver.packets <---新增了PATCH
end.sum_receiver.lost_packets <---带有PATCH的新功能

如果我错了，请纠正我！

“结尾”： {
“总和”：{
“结束”：10.00，
“秒”：10.00，
“ bits_per_second”：1058280.26，
“字节”：1322892，
“数据包”：81，
“开始”：0，
“ jitter_ms”：0.056，
“ lost_packets”：0，
“ lost_percent”：0
}，
“信息流”：[
{
“ udp”：{
“结束”：10.00，
“ socket”：5
“秒”：10.00，
“ bits_per_second”：1058280.26，
“字节”：1322892，
“数据包”：81，
“ out_of_order”：0，
“开始”：0，
“ jitter_ms”：0.056，
“ lost_packets”：0，
“ lost_percent”：0
}
}
]，
“ sum_sender”：{<---新增了PATCH
“结束”：10.00，
“秒”：10.00，
“ bits_per_second”：1058280.26，
“字节”：1322892，
“数据包”：81，
“开始”：0，
“ jitter_ms”：0，
“ lost_packets”：0，
“ lost_percent”：0
}，
“ sum_receiver”：{<---新增了PATCH
“结束”：10.00，
“秒”：10.00，
“ bits_per_second”：1058271.16，
“字节”：1322892，
“数据包”：81，
“开始”：0，
“ jitter_ms”：0.0568，
“ lost_packets”：0，
“ lost_percent”：0
}

谢谢

-一种

2018年9月13日星期四，上午10:04布鲁斯·马（Bruce A.Mah） [email protected]
写道：

@awardblvr https://github.com/awardblvr ：我猜这取决于你
定义“成功”。 我想一种措施可能是
end.sum.lost_packets为零，则接收方未检测到任何丢失
包。 但是，有一些边缘情况，主要是必须要做的
当客户端仍在运行的数据包发生了什么情况
宣布测试完成。

-
您收到此邮件是因为有人提到您。
直接回复此电子邮件，在GitHub上查看
https://github.com/esnet/iperf/issues/584#issuecomment-421079759或静音
线程
https://github.com/notifications/unsubscribe-auth/AFE_e3JCfwSxfr_negMTgZCq8Z6xIkdlks5uapAegaJpZM4NgILa
。

由于缺少用于UDP的独立Tx / Rx B / W，遇到了类似的问题。
采取了不同的方法。

我使用TxRate和Drop％计算了RxMbps。

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

服务器-10Mbps --- SRX（路由器）--- 5Mbps -----客户端
（应用在SRX接口上的流量整形器）

我在20Mbps的速度下测试两个方向。

iPerf3 UDP上传：

远程：10.8.8.100
本地：10.9.9.222
协议/端口：UDP / 33333
开始时间：2021年1月10日，星期日，格林尼治标准时间
持续时间（秒）：10
传输速率：20.0Mbps
接收速率：9.58Mbps
抖动：0.7毫秒
丢失的数据包：8990
失落率：52.07％
本地CPU：9.03％
远程CPU：0.76％

iPerf3 UDP下载：

远程：10.8.8.100
本地：10.9.9.222
协议/端口：UDP / 33333
开始时间：2021年1月10日，星期日，格林尼治标准时间
持续时间（秒）：10
传输速率：20.0Mbps
接收速率：4.82Mbps
抖动：0.49毫秒
丢失的包裹：13172
失落率：75.9％
本地CPU：2.5％
远程CPU：8.26％

@ hakujin22 ，“ _ RxMbps = TxMbps-（TxMbps *（result.lost_percent / 100））_”通常不会起作用。 这是因为数据仅在本地收集，而不是从远端收集。 例如，在您发送的数据中，服务器到客户端的端到端链接带宽为5Mbps。 但是，假设“上传是服务器到客户端”，则服务器上的速度为10Mbps。 这是因为这是服务器到SRX吞吐量的衡量标准，而不是端到端的衡量标准。

@ bmah888 ，因为可以使用--server-output接收服务器数据，所以以下方法可以用作UDP JSON摘要统计信息问题的解决方案/解决方法：

1. “ _sum_received_”和“ _sum_sent_” JSON部分将添加到服务器和客户端上的UDP _end_摘要中。 这些部分将不会代替_sum_部分。
2. “ _sum_received_”将仅包括来自接收器的非零数据。 例如，当使用-R或双向时，客户端将设置它，但是仅当发送者时，客户端将设置为零。
3. “ _sum_sent_”将使用类似的规则进行设置，但适用于发送方或双向。

这种方法似乎与当前解决方案向后兼容。 如果您同意，这可能是一种有用的方法，那么我将尝试实现它。