1

ゲートウェイの入り口と出口の NIC で tcpdump を使用してパケットをキャプチャすることにより、ゲートウェイ内のパケットが直面する遅延または待ち時間を測定しています。送信元ホストから 2 つの GW を介して接続されている宛先ホストに約 800,000 のパケットを送信しています (つまり、送信元ホスト => GW1 => GW2 => 宛先ホスト)。入口 NIC のタイムスタンプを出口 NIC のタイムスタンプから差し引くことで、各 GW のレイテンシを測定しました。レイテンシが 2 から 3000 マイクロ秒に増加し続けていることがわかりました。NIC を交換したところ、しばらくの間レイテンシが増加し、急激に減少して再び増加しました。

そして驚くべきことに、すべてのノードに 1000Mbps の NIC がある場合、GW のレイテンシが増加しても、エンドツーエンドのスループットは約 900Mbps のままです。

このようなレイテンシの変動がどのように発生したか教えてください。または、出口 NIC で tcpdump タイムスタンプがどのように遅れたのでしょうか? ナノ秒の粒度でタイムスタンプを取得する方法はありますか?


返信ありがとうございます。

インフラストラクチャのパフォーマンスは問題ありません。ここではスループットでパフォーマンスを測定しており、GW のレイテンシが 2 マイクロ秒から 3000 マイクロ秒に増加してもスループットが低下しないことがわかりました。

追加情報: GW が IP ルーター、GRE トンネリング ポイント、NAT などのさまざまな役割を果たしているときの GW の待ち時間を測定してきました。IP ルーターとして機能する場合、GW 内のパケットで発生する遅延は、ほぼ 4 マイクロ秒以下です。ただし、GW が GRE トンネリング ポイントとして機能する場合、遅延は数秒間で 1000 倍に増加します。これが私の測定の問題です。また、エンド ツー エンドのスループットに変化がないため、この遅延は実際のものではなく、tcpdump のパケット キャプチャおよびタイムスタンプ機能によって導入された可能性があると思います。

4

1 に答える 1

1

私はここであまりにも明白に考えているかもしれませんが、あなたが言及しているのは、日常生活の事実であるジッターと単純なパケット遅延の変動であると考えています.

最近では、CPU サイクルを節約するために、 NIC にTCP オフロードがあり、パフォーマンスは NIC によって異なります。これが、切り替え時の違いの原因となる可能性があります。

あなたが言及した小さな時差を考えると、インフラストラクチャのパフォーマンスに問題を引き起こしていますか?

また、2 つのゲートウェイのパフォーマンスを監視して、待機時間の変化がゲートウェイの負荷の増加に対応しているかどうかを確認する必要があります。

于 2012-08-10T16:43:34.483 に答える