iperfおよびtcpdumpでのパケット損失率

回線のリンク品質をでテストしましたiperf。測定された速度（UDPポート9005）は96Mbpsでした。これは、両方のサーバーが100Mbpsでインターネットに接続されているためです。一方、データグラムの損失率は3.3〜3.7％であり、少し多すぎることがわかりました。高速転送プロトコルを使用して、で両側のパケットを記録しましたtcpdump。パケット損失を計算した場合よりも、平均0.25％。この大きな違いがどこから来ているのか、誰か説明がありますか？あなたの意見では許容できるパケット損失とは何ですか？

CPUが追いつかないために、UDPモードのiPerfで大幅なデータ損失が発生しました。何らかの理由で、UDPとiperfのはあると思われるくらいの TCPとiperfのより集中的な多くのCPU。iPerfをレートの半分に設定すると、同じ損失率が発生しますか？

許容可能なパケット損失の量に関する2番目の質問に答えるには、実際に実行しているアプリケーション、取得したトラフィックの量によって異なります。実際には、帯域幅の制限を下回っていても損失はありません。ほとんどの場合、おそらく.25％についてあまり文句を言わないでしょうが、本当に高いレートで実行している場合は、それでも多くの損失です。

[編集1]このトピックについて私が持っていた他のいくつかの考え：

1. iPerfのレートを増やしてみてください。どこかに体系的な問題がある場合、どのような率であっても同じ割合の損失が発生する可能性があります。ハードウェアの限界に達している場合、またはプロバイダーが何らかのREDを実行している場合、特定のレートまでは損失が発生しない可能性が高く、その後は損失が大きくなるほど損失が大きくなります。
2. テストが正確であることを確認するためだけに、iPerfセッションのtcpdump測定を行います。
3. TCPでiPerfを試してください。これは損失を報告しませんが、損失が発生している場合、接続は非常に大きくスケールアップできません。レイテンシもこれに影響するので、レイテンシができるだけ少ないエンドポイントまでテストしてください。
4. 接続の内側にあるギアに応じて、できるだけ近づけてください。たとえば、テストシステムとエッジルーターの間に複数のスイッチがある場合は、直接接続されているスイッチに移動します。
5. 管理されたスイッチがある場合は、そのスイッチの統計をチェックして、そこで損失が発生していないことを確認します。100 Mbpsに近いUDPトラフィックが得られるとドロップが始まる安価なスイッチがいくつか見つかりました（ただし、ほとんどが古くて安価な非管理型スイッチ）。
6. 2つの異なるクライアントから2つの異なるホストに同時にiPerfsを試してください。そうすれば、制限がCPUや安価なローカルNICカードの結果ではないことを確認できます。

まあ、TCPには1つのフローの利用率を最大化するメカニズムがありますが、UDPにはありません。したがって、各アプリケーションは独自のメカニズムを作成する必要があります。そのため、おそらく各アプリケーションは異なるアプローチを使用してそれを行います。おそらく、Iperfは、情報が受信されたかどうかを気にせずに、使用可能な最大帯域幅に到達しようとするため、より多くのパケットが失われることを許可します。他のアプリケーションは、多くのパケットを失わないようにして、接続で使用可能なスループットまでパケットレートを下げます。

tcpdumpで計算したパケット損失がiperfと一致することを確認するために、iPerfを使用しているときにtcpdumpを使用してパケット損失をチェックしましたか？

あなたの測定方法が比較できないことに気付くかもしれません。

iperfは、UDPで順序どおりに到着しないパケットを自動的に破棄しますか？接続のジッターを少し見ているかもしれません。