問題タブ [packet-loss]

マルチキャスト経由で UDP パケットを送信するサーバーと、それらのマルチキャスト パケットにリストされている多数のクライアントがあります。各パケットのサイズは 1040 バイトの固定サイズで、サーバーから送信されるデータ全体のサイズは 3G バイトです。

私の環境は次のとおりです。

1 ギガビット イーサネット ネットワーク

40 のノード、1 つの送信側ノードおよび 39 の受信側ノード。すべてのノードのハードウェア構成は同じです: 2 つの AMD CPU、各 CPU には 2 つのコア @2,6GHz があります。

クライアント側では、1 つのスレッドがソケットを読み取り、データをキューに入れます。追加の 1 つのスレッドがキューからデータをポップし、軽い処理を行います。

マルチキャスト送信中に、ノード側で 30% のパケット ドロップ率を認識します。netstat –su 統計を観察することで、クライアント アプリケーションによって欠落しているパケットは、netstat 出力の RcvbufErrors 値と同じであると言えます。

これは、ソケット バッファがいっぱいになったため、不足しているすべてのパケットが OS によってドロップされたことを意味しますが、キャプチャ スレッドがバッファを時間内に読み取れない理由がわかりません。送信中、4 つのコアのうち 2 つが 75% 使用され、残りはスリープ状態です。これらのノードを使用しているのは私だけですが、この種のマシンは 1 ギガビットの帯域幅を問題なく処理できると思います。amd cpus に g++ コンパイラ フラグを追加することで、既にいくつかの最適化を行っています。これにより、パケット ドロップ率が 10% に減少しますが、それでも私の意見では高すぎます。

もちろん、UDP が信頼できないことはわかっています。私は独自の修正プロトコルを持っています。

管理権限がないため、システム パラメータを変更することはできません。

どうすればパフォーマンスを向上させることができますか？

編集:ソケットを読み取っている2つのスレッドを使用して、この問題を解決しました。recv ソケット バッファがいっぱいになることがあります。しかし、平均ドロップは1%未満なので、対処するのに問題はありません。

すべてを次々に送信するのではなく、複数のUDPパケットを1つに結合することには利点がありますか？大きなパケットが破損した場合、私はそれらをすべて失うことを知っていますが、それらをすべて1つに送信することにはおそらくいくつかの利点がありますか？大きなものが失われる可能性が低いなど？

パケット損失とパケット重複の問題の違いを調べようとしています。「パケットの複製」とは何か知っている人はいますか？TCPで損失が検出されたときにパケットを再送信するのと同じですか？

200Mbpsの速度でUDPパケットを送信するサーバーアプリケーションがあります。出力イーサネットインターフェイスは1000Mbpsです。しかし、UDPパケットは不規則な間隔で損失をバーストします。パケット損失の問題が発生している限り、フィールドSndbufErrorsが増加していることに気づきました。/proc/net/snmpUDPパケットがloopbackインターフェイスに送信される場合、パケット損失は存在しません。

によるエラーリターンはありませんudp.send。

Linuxカーネルを掘り下げましたが、ルートサブシステムに到達したときに行方不明になっています。

どういうSndbufErrors意味ですか？なぜ数が増えるのですか？

CoreAudioのパケット損失を隠す基本的なアルゴリズムを作成しようとしています。欠落しているデータを無音に置き換えたいだけです。コアオーディオを学習する本では、著者は、ロスレスPCMでは、ゼロは無音を意味すると述べています。VBR（つまり圧縮データ）を再生しているのかどうか疑問に思っていましたが、沈黙にはゼロを入れるだけで十分でしょうか？

私の既存のコードでは、オーディオキューにゼロを接続すると、突然ジャムが発生し（つまり、オーディオキューのコールバックで消費されたデータが解放されなくなります）、なぜだろうと思います。

RTPを受信するC++プログラムでパケット損失の問題をデバッグしています。私のプログラムは、大量のRTPデータを受信して​​かなり長い間実行された後、パケットを失い始めます。

Wiresharkでトレースすると、欠落しているパケットが表示されますが、アプリケーションがそれらを受信することはありません。ネットワークスタックは、それらをアプリケーションに配信する前にそれらをドロップするようです。アプリケーションを再起動すると、すべてが正常に戻ります。

エラー状態を生成するために、RTPでマシンを過負荷にすると、その時点でパケット損失が発生しますが、これには正当な理由があります。しかし、過負荷を停止して適度な速度で送信を開始した後でも、パケット損失が発生するため、すべてのデータを再度受信するには、アプリケーションを再起動する必要があります。

これはLinuxの受信バッファ処理の問題ですか？欠落しているパケットがどこに行くかを確認するために、どのLinux統計を確認できますか？

UDP で小さなパケットをたくさん送信すると、より多くのリソース (CPU、zlib による圧縮など) が必要になります。私はここで、UDP で ~65kBYTE の大きなパケットを 1 つ送信するとおそらく失敗することを読んだので、小さなパケットをたくさん送信するとより頻繁に成功すると考えられますが、より多くの処理能力を使用することによる計算上のオーバーヘッドが発生します (または、少なくともそれは私が仮定しています）。問題は基本的にこれです。成功した最大のパケットを送信し、計算を最小限に抑えるための最良のシナリオは何ですか? ほとんどの場合に機能する特定のサイズはありますか? サーバーには Erlang を、クライアントには Enet を使用しています (c++ で記述)。Zlib 圧縮も使用して、同じパケットをすべてのクライアントに送信します (ブロードキャストは私が推測する用語です)。

パケット損失を有効にする良い方法を探しています。ubuntuのこのコマンドに出くわしました。このコマンドは、インターフェイス wlan11 が受信するパケットの 10% (0.10) を失うようにすることになっています。

このコマンドは使いやすいですか、それとも私が使用できるより良い/簡単なコマンド/方法はありますか?

ありがとうございました。

さて、私はネットワーキングコースのプログラミングをしていて、UDPを使用してJavaでプロジェクトを実装する必要があります。指定された確率でパケットを破損する「gremlin」関数とともに、HTTPサーバーとクライアントを実装しています。HTTPサーバーは、UDPを介してクライアントに送信するために、アプリケーション層で大きなファイルを複数のセグメントに分割する必要があります。クライアントは、受信したセグメントをアプリケーション層で再構築する必要があります。しかし、私が疑問に思っているのは、UDPが定義上信頼できない場合、なぜここで信頼性の欠如をシミュレートする必要があるのでしょうか。

私の最初の考えは、おそらく私のインストラクターが私たちの場合を考えているからだと思います。クライアントとサーバーの両方が同じマシンで実行され、ファイルはUDPを介しても100％確実に1つのプロセスから別のプロセスに転送されます。同じコンピューター上の2つのプロセスの間にあります。

これにより、サーバーとクライアントが同じ物理マシン上の2つのプロセスであり、厳密にルーティングされることが保証されている場合、UDPが実際にパケットを失ったり、パケットを破損したり、パケットを順不同で配信したりする可能性があるかどうかを最初に疑問視しました。 localhostを介してのみ、ネットワークを介して送信されないようにします。

また、一般的に、特定のパケットについて、かなり地理的に離れた2つのホスト間のオープンインターネットを介した通信を容易にするために使用されているときに、UDPがパケットをドロップ/破損/または順序どおりに配信しないおおよその確率を知りたいと思います。互いに離れている（米国の平均的なブロードバンドユーザーからGoogleのCDNの1つまでのルートに匹敵するものを言う）？私は主に、UDPを介して通信するときに発生する状態の概要を把握しようとしています。それは、パケットの25％程度の何かをドロップ/破損/誤順序付けするのでしょうか、それとも0.001％程度の何かのようなものですか。パケット？

私のためにこれらの質問のいずれかに光を当てることができる人に感謝します。