Iperf: UDPのレシーバー帯域幅が欠落しているJSON出力

正しい。 これは非常に古いバグであり、最初からiperf3に存在していた可能性があります。 ＃562の作業をしているときに、ある種気づきました（なぜ問題を提出しなかったのですか？）。 あなたが正しく指摘したように、UDPテストはクライアント側とレシーバー側の統計を別々に分割しません。 報告されているのがクライアントなのか、送信者なのか、それとも2つのミッシュマッシュなのかはわかりません。 TCPがなぜ違うのかも私にはわかりません。

既存のJSONを消費するプログラムとの何らかの互換性を維持する方法はわかりませんが、UDPテストがこの点でTCPに似た統計出力を出力できれば（送信側と受信側の両方で別々に）良いことです。出力。 （＃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がゼロの場合、受信者は失われたパケットを検出しなかった可能性があります。 ただし、これにはいくつかのエッジケースがありますが、ほとんどの場合、クライアントがテストの完了を宣言したときにまだ送信中のパケットに何が起こるかと関係があります。

ありがとう...、私はこの1つの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、
「ソケット」：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
}

ありがとう

-A

2018年9月13日木曜日午前10:04ブルースA.マー[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日日曜日03:51:23 GMT
持続時間（秒）：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日日曜日03:51:38 GMT
持続時間（秒）：10
送信速度：20.0Mbps
受信速度：4.82Mbps
ジッタ：0.49ミリ秒
失われたパケット：13172
失われた割合：75.9％
ローカルCPU：2.5％
リモートCPU：8.26％

@ hakujin22 、 "_ RxMbps = TxMbps-（TxMbps *（result.lost_percent / 100））_"はおそらく一般的には機能し

@ bmah888 、サーバーデータは--server-outputを使用して受信できるため、 UDPJSON要約統計量の問題の解決策/回避策として次のアプローチを使用できます。

1. 「_sum_received_」および「_sum_sent_」JSONセクションは、サーバーとクライアントの両方のUDP_end_サマリーに追加されます。 これらのセクションは、_sum_セクションに置き換わるものではありません。
2. 「_sum_received_」には、レシーバーからのゼロ以外のデータのみが含まれます。 たとえば、クライアントは-Rまたは双方向が使用されている場合は設定しますが、送信者のみが使用している場合はゼロに設定します。
3. 「_sum_sent_」は同様のルールを使用して設定されますが、送信者または双方向用です。

このアプローチは、現在のソリューションと下位互換性があるようです。 あなたがこれを承認するなら、これは使用可能なアプローチかもしれません。私はそれを実装しようとします。