タグ付けされた質問 「packetloss」

マシンとの間のTCP接続でのパケット損失を受動的に監視するにはどうすればよいですか？ 基本的に、バックグラウンドにあり、TCP ack / nak / re-transmitsを監視して、どのピアIPアドレスが「大きな損失」を経験しているように見えるかのレポートを生成するツールが欲しいです。 私がSFで見つけたこのような質問のほとんどは、iperfなどのツールを使用することをお勧めします。しかし、マシン上の実際のアプリケーションとの接続を監視する必要があります。 このデータはLinux TCPスタックにそのまま存在しますか？

61 linux  tcp  performance-monitoring  network-monitoring  packetloss 

4つのNIC（1 Gbps）を備えたゲートウェイとして機能する最小のCentOS 6.3、64ビットがあり、それぞれがパブリックトラフィック用とプライベートトラフィック用に結合され、NATを実行します。6 GBのRAMと4つの論理コアを備えています。過去2年間これを問題なく使用しています。 ハードウェアルーターの経験はありませんが、RAMとCPUが少なく、フラッシュディスクを使用していると聞きました。低いハードウェア構成のボックスは、より多くのRAMとCPUを搭載したマシンよりも優れたパフォーマンスを発揮します（たとえば、より多くの同時接続を処理できます）。 これを処理するために異なる方法を使用するIOS以外の制限要因は何ですか？

44 linux  router  packetloss 

これは非常に主観的であり、多くの変数に依存していることを理解していますが、特定のシステムでパケット損失を診断する必要がある場合、ほとんどの人がどのステップを踏むのか疑問に思っていますか？

27 best-practices  packetloss  packet 

iperf3クライアントとして使用するLinuxボックスがあり、2台の同じ装備のWindows 2012 R2サーバーボックスとBroadcom BCM5721、1Gbアダプターをテストしています（2つのポート、ただしテストに使用したのは1つだけです）。すべてのマシンは、単一の1Gbスイッチを介して接続されます。 300MbitなどでのUDPのテスト iperf3 -uZVc 192.168.30.161 -b300m -t5 --get-server-output -l8192 送信されたすべてのパケットの14％が失われます（まったく同じハードウェアを備えた他のサーバーボックスの場合、古いNICドライバーの場合、損失は約2％です）が、それほど深刻ではありませんが、50Mbitでも損失が発生します。同等の設定を使用したTCPパフォーマンス： iperf3 -ZVc 192.168.30.161 -t5 --get-server-output -l8192 報告された再送信なしで800Mbitの北の伝送速度をもたらします。 サーバーは常に次のオプションを使用して起動されます。 iperf3 -sB192.168.30.161 誰のせいですか？ Linuxクライアントボックス（ハードウェア？ドライバー？設定？）？ 編集： Windowsサーバーボックス間でテストを実行したところ、300MbitのUDPパケット損失はさらに大きく、22％でした Windowsサーバーボックス（ハードウェア？ドライバー？設定？）？ すべてのテストマシンを接続する（単一の）スイッチですか？ ケーブル？ 編集： 今、私は別の方向を試してみました：Windows-> Linux。結果：パケット損失は常に0ですが、スループットは約で最大になります 840Mbit -l8192、つまりフラグメント化されたIPパケット 250Mbit for -l1472、断片化されていないIPパケット フロー制御はスループットを制限し、パケット損失を防ぐと思います。特に後者の、断片化されていない数値はTCPスループットに近いところにありません（断片化されていないTCPは断片化されたTCPと同様の数値をもたらします）が、パケット損失の点でLinux-> Windowsをはるかに上回る改善です。 そして、どうやって見つけるのですか？ サーバーのドライバー設定に関する通常のアドバイスに従ってパフォーマンスを最大化し、有効化/無効化/最大化/最小化/変更を試みました 割り込みモデレーション フロー制御 受信バッファー RSS ウェイクオンLAN すべてのオフロード機能が有効になっています。 編集私も有効/無効にしようとしました イーサネット@ワイヤスピード …

11 performance  tcp  udp  packetloss  iperf 

rsync次のコマンドを使用して、サーバー上のファイルを更新しようとしています： rsync -ravq -e "ssh -o ConnectTimeout=2 -o ServerAliveInterval=2 -ServerAliveCountMax=2" --delete ./local_dir user@$SERVER:/dest_dir corrupt packet エラーがスローされ続けます、具体的には： rsync: writefd_unbuffered failed to write 4092 bytes to socket [sender]: Broken pipe (32) rsync: connection unexpectedly closed (11337 bytes received so far) [sender] rsync error: unexplained error (code 255) at /home/lapo/package/rsync-3.0.9-1/src/rsync-3.0.9/io.c(605) [sender=3.0.9] ssh大きな（r）ファイルで発生するように思われるため、これはおそらくタイムアウトに関連しています。また、WinSCPを使用してタイムアウトが発生し続けます。これは私だけに起こっています。このサーバーを使用している私と一緒に働く人々の何人かは同じ問題を抱えていません。 rsyncCentos …

10 ssh  rsync  corruption  packetloss 

同じデータセンターに2台のマシンがあるとしますが、必ずしも同じラックにあるとは限りません。 これらの2つのマシン間でUDPを使用して送信された場合、パケットのドロップはどのくらい一般的ですか？ 私は、マシン間にせいぜい数個のスイッチしかないので、パケットがまったくドロップされないという仮定の下で質問しています。 同じデータセンター内でのパケットの到着の乱れはどのくらい一般的ですか？私の仮定では、99.9％の時間しかルートがないため、これは起こり得ません。 しかし、絶対的なことを考えているときはいつでも、何かを見逃しているに違いないことを知っています。 パケットのドロップが予想されるタイミング、およびそれらがドロップされて同じデータセンター内のマシンの順序が狂ってしまう頻度をよりよく理解するには、どのような背景情報が必要ですか？ 最終的に、同じデータセンターにある異なるLinode VPSインスタンス間で通信するときに、マルチキャストUDPまたはPGMのどちらを使用するかを決定しようとしています。情報が到着し、順番に並んでいる必要があります。もちろん、UDPはそれほど素晴らしい音ではありません！ ただし、同じデータセンターでほぼ完全な、または完全な配信が期待できる場合は、問題ありません。しかし、私はその仮定をテストしています。 ありがとう。

10 networking  udp  multicast  datacenter  packetloss 

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

10 tcpdump  packetloss  iperf