Iperf: 奇妙な不一致の動作UDPOUT OF ORDER

これは、iperf3サーバーが、iperf3クライアントから送信された順序とは異なる順序でUDPテストパケットを受信して​​いることを意味します。 この現象には、ネットワークを介してさまざまなパスをたどるパケットからネットワークドライバのバグまで、さまざまな説明が考えられます。

誰かが問題の診断を手伝うには、より多くの情報が必要になります。 宛先で（たとえばtcpdumpを使用して）パケットトレースを取得すると、実際にパケット内のiperf3シーケンス番号をデコードして、パケットが無傷で到着したか、順序が狂っているかなどを確認できます。

ボンディングされたリンクまたはボンディングされたNICがある可能性がありますか？ これにより、パケットの順序が狂うことがよくあります。

また、3.1.6で修正されるかどうかも確認してください。

@ bmah888 ：

プロトコルとしてのUDPは、パケットが送信されたのと同じ順序で到着することを保証しないのに、なぜ順序が狂ったパケットが統計出力で「失われた」パケットとしてカウントされるのですか？

たとえば、以下のUDPテスト出力では、両端でiperfの最新のf1415a0d98bコミットを使用し、コマンドiperf3 -R -u --get-server-output -b 4M -c <my_server_hostname>を使用すると、いくつかの「OUT OF ORDER」メッセージがあり、その直後に、それらのアウトオブオーダーパケットは次のようになります。失われたパケットとして報告されます（例： 2/342 ）。 なぜ彼らは失われたと数えられるのですか？ これはUDPであるため、異常なパケットは完全に通常の状況で発生する可能性があります。

Connecting to host xxx, port 5201
Reverse mode, remote host xxx is sending
[  4] local 192.168.1.110 port 56316 connected to yyy port 5201
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-1.00   sec   510 KBytes  4.18 Mbits/sec  1.091 ms  0/358 (0%)
iperf3: OUT OF ORDER - incoming packet = 537 and received packet = 538 AND SP = 4
[  4]   1.00-2.00   sec   489 KBytes  4.01 Mbits/sec  1.111 ms  1/343 (0.29%)
[  4]   2.00-3.00   sec   488 KBytes  3.99 Mbits/sec  0.439 ms  0/342 (0%)
[  4]   3.00-4.00   sec   489 KBytes  4.01 Mbits/sec  1.150 ms  0/343 (0%)
iperf3: OUT OF ORDER - incoming packet = 1562 and received packet = 1563 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 1581 and received packet = 1582 AND SP = 4
[  4]   4.00-5.00   sec   488 KBytes  3.99 Mbits/sec  1.397 ms  2/342 (0.58%)
iperf3: OUT OF ORDER - incoming packet = 2002 and received packet = 2004 AND SP = 4
[  4]   5.00-6.00   sec   488 KBytes  4.00 Mbits/sec  1.180 ms  1/342 (0.29%)
[  4]   6.00-7.00   sec   489 KBytes  4.01 Mbits/sec  0.753 ms  0/343 (0%)
[  4]   7.00-8.00   sec   489 KBytes  4.01 Mbits/sec  0.989 ms  0/343 (0%)
[  4]   8.00-9.00   sec   488 KBytes  3.99 Mbits/sec  2.294 ms  0/342 (0%)
[  4]   9.00-10.00  sec   486 KBytes  3.98 Mbits/sec  1.401 ms  0/341 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.06  sec  4.80 MBytes  4.00 Mbits/sec  0.000 ms  0/3445 (0%)  sender
[SUM]  0.0-10.1 sec  4 datagrams received out-of-order
[  4]   0.00-10.00  sec  4.80 MBytes  4.02 Mbits/sec  1.361 ms  4/3445 (0.12%)  receiver

Server output:
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from zzz, port 35815
[  6] local yyy port 5201 connected to zzz port 39455
[ ID] Interval           Transfer     Bandwidth       Total Datagrams
[  6]   0.00-1.00   sec   489 KBytes  4.01 Mbits/sec  343
[  6]   1.00-2.00   sec   488 KBytes  3.99 Mbits/sec  342
[  6]   2.00-3.00   sec   489 KBytes  4.01 Mbits/sec  343
[  6]   3.00-4.00   sec   488 KBytes  3.99 Mbits/sec  342
[  6]   4.00-5.00   sec   489 KBytes  4.01 Mbits/sec  343
[  6]   5.00-6.00   sec   488 KBytes  3.99 Mbits/sec  342
[  6]   6.00-7.00   sec   488 KBytes  3.99 Mbits/sec  342
[  6]   7.00-8.00   sec   489 KBytes  4.01 Mbits/sec  343
[  6]   8.00-9.00   sec   488 KBytes  3.99 Mbits/sec  342
[  6]   9.00-10.00  sec   489 KBytes  4.01 Mbits/sec  343
[  6]  10.00-10.06  sec  28.5 KBytes  4.01 Mbits/sec  20
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  6]   0.00-10.06  sec  4.80 MBytes  4.00 Mbits/sec  0.000 ms  0/3445 (0%)  sender


iperf Done.

@AndrewJDR ：正直なところ、なぜそれがエラーをカウントしているのかは

私の推測では（そしてそれだけです）、2つのパケットが交換された場合、受信したシーケンス番号にギャップがあるように見え、（誤って）損失としてカウントされます。 つまり、パケットがABCDの順序で送信され、ACBDの順序で受信された場合、iperf3は、BとDの間でパケットが失われたと考えている可能性があります。もちろんそれは起こりません。 現時点では、これ以上の洞察はありません。

理想的には、iperf3は、損失と故障を別々に追跡するのに十分スマートであると思います。 明らかに、順不同のパケットは「損失」カウンターに表示されるべきではありません。

問題のコードはiperf_udp_recvにあり、抜粋は以下のとおりです。

    /* Out of order packets */
    if (pcount >= sp->packet_count + 1) {
        if (pcount > sp->packet_count + 1) {
            sp->cnt_error += (pcount - 1) - sp->packet_count;
        }
        sp->packet_count = pcount;
    } else {
        sp->outoforder_packets++;
    iperf_err(sp->test, "OUT OF ORDER - incoming packet = %zu and received packet = %d AND SP = %d", pcount, sp->packet_count, sp->socket);
    }

pcountは、到着するUDPパケットから読み取られたシーケンス番号です。 sp->packet_countは、これまでに見られた最大のシーケンス番号です。 はい、名前が間違っているようです。この値は、ストリームで受信されたパケットの総数とは関係がない可能性があります。 基本的に、最初の条件付きチェックでは、到着したパケットによってシーケンス番号が順方向または逆方向に進むかどうかが確認されます。 転送する場合、ギャップのサイズをsp->cnt_error追加することにより、ギャップ（存在する場合）を失われたパケットとしてカウントします。 次に、次に予想されるシーケンス番号を設定します。

パケットシーケンス番号が逆になっている場合は、順不同のカウンターsp->outoforder_packetsをインクリメントし、実際のシーケンス番号と予想されるシーケンス番号、およびファイル記述子を含む少し紛らわしいエラーメッセージを出力します。 エラーメッセージはstderrに送られますが、これは間違いだと思います（個々のパケット損失はログに記録されないことに注意してください）...そのエラーメッセージをデバッグフラグまたは詳細フラグの背後に隠す方がよい場合があります。

パケットのシーケンスがシーケンス番号（1、2、3、4）で送信されたが、何らかの理由でシーケンス（1、3、2、4）で受信されたとしましょう。 パケット1は問題なく処理されます。 パケット3の受信は損失としてカウントされますが（iperf3はパケット2がドロップされたと見なすため）、受信者は次にパケット4を予期します。 パケット2が実際に受信され、これによりアウトオブオーダーカウンタがインクリメントされます（ただし、パケット4は次に予想されるパケットのままです）。 最後に、パケット4が受信者に到着します。これは期待値です。 この一連のパケットは、実際には実際の損失がなかったとしても、1つの異常なパケットと1つの損失としてカウントされます。

受信するすべての異常なパケットについて、損失の数を減らすことができるのは（もっと）正しいと思います（シーケンス番号にギャップが必要なため、その数は常にゼロ以外である必要がありますパケットの重複がないと仮定して、パケットの順序が狂っています）。 パケットが重複したり、損失と並べ替えの組み合わせが発生したりして、これが失敗する奇妙なエッジケースがあると確信していますが、このようなシナリオで損失を正確にカウントする唯一の方法は、すべてのシーケンス番号と、実際に見たシーケンス番号にチェックマークを付けます。 それはかなり面倒に感じます。

そのため、この時点で、順不同の処理を少し調整し、now-errorメッセージを変更し、コードの動作を説明する内部ドキュメントを追加することを検討しています。 しかし、これをテストする簡単な方法はありません...ある程度制御された方法でこれをテストする方法についての提案があります。

@ bmah888異常なパケットやパケット損失をテストする場合は、Linuxで「tc」ツールを使用できます。
https://wiki.linuxfoundation.org/networking/netem#packet -re-ordering

例：

# First add a qdisc:
tc qdisc add dev eth0 root netem delay 1ms # Simulates 1ms of delay
# After running "qdisc add", to simulate packet loss:
tc qdisc change dev eth0 root netem loss 1%
# Alternatively, for simulating re-ordering:
tc qdisc change dev eth0 root netem gap 5 delay 10ms # re-orders every 5th packet
# To switch between loss/re-ordering, first run:
tc qdisc del dev eth0 root
# Then run "tc qdisc add" and the appropriate "tc qdisc change" command above...

これらのコマンドを実行した後、通常どおりiperfを実行し（送信者として「tc」を実行したマシンを使用）、パケット損失または再注文を観察する必要があります。

ループバックアダプタでテストを実行する場合は、「eth0」ではなく「lo」を使用してこれらのコマンドを使用することもできます。

（これらのコマンドを使用する方法はおそらくもっと簡潔ですが、これは私が慣れている方法です。）

@AndrewJDR ：情報をありがとう、それは私が始めるのに大きな助けになりました。 私が使用しているCentOS7 VMでは、次のように少し異なることを行う必要があります。

tc qdisc add dev lo root netem delay 1ms
tc qdisc change dev lo root netem reorder 100 gap 5 delay 10ms

現在、このサーバーでテストしています。

bmah-centos7:iperf% src/iperf3 --server

そしてこのクライアント：

bmah-centos7:iperf% src/iperf3 --client localhost --udp -b 15m

クライアントでUDP送信ビットレートを上げる必要がありました。これは、デフォルトでは、パケットの間隔が十分に狭くないため、netemの並べ替えが効果を発揮できないためです。 15Mbpsは十分に高速であるため、ある程度の並べ替えが見られますが、出力に圧倒されることはありません。

@ bmah888ありがとうございます...次回iperfテストを実行するときにこれを試して、どのように機能するかをお知らせします。

以前の動作がかなり壊れていて、いわゆるソリューションが機能しなくても悪化する可能性がないという理由で、いくつかのテストの後にそのプルリクエスト（＃589）をマスターにマージしました。 ところで、すべてのケースで完全に正しいとは思いませんが、私がテストしてきたケースでは正しく（またはほぼ正しく）カウントされます。 今のところこの問題を閉じています...必要に応じて再度開くことができます。