ポーズフレームがネットワーク接続に与える潜在的な影響は何ですか。

イーサネットフロー制御の目的：

イーサネットフロー制御は、パフォーマンスのボトルネックが発生しているネットワークデバイスが、隣接デバイスの送信を停止するように要求するメカニズムです。イーサネットフロー制御は、通常は「ポーズ」フレームと呼ばれるイーサネットパケットのタイプを定義します。これらは、直接接続されているデバイス間でのみ交換でき、イーサネット（データリンク）レイヤでのみ定義されます。したがって、イーサネットポーズフレームは関連付けられておらず、 IP 、 TCP 、 NFS 、 CIFS 、またはその他の上位レベルのプロトコルには関連付けられません。

イーサネットフロー制御を使用しない場合、受信側デバイスが送信側デバイスと同じ速度で情報を処理できない場合、最終的には着信データの廃棄を開始する必要があります。これにより、送信側クライアントは強制的に再送信しなければならなくなり、さまざまな理由で、面倒な遅延が発生する可能性があります。

イーサネットフロー制御を使用すると、受信者は送信側デバイスに「一時停止」を短時間要求して、これらの廃棄を回避できます。場合によっては、ネットワーク転送の効率が向上することもあります。ただし、イーサネットフロー制御は、パフォーマンスの問題を防ぐために必ずしも有効ではありません。イーサネットフロー制御は、特定の（通常はまれな）状況において、意図された再送信によるパフォーマンスへの影響よりも大きな影響を与える可能性があります。

注：イーサネットフロー制御は、 1Gbps 以上の機器で共通になります。また、イーサネットフロー制御仕様がサポートされていないにもかかわらず、最新の 100 Mbps 機器でも使用されている場合があります。

例：

ストレージコントローラ、スイッチ、およびクライアントマシンを備えた基本的なネットワークがあるとします。さらに、ストレージコントローラがイーサネットフロー制御パケットを送信するように設定され、ストレージコントローラが接続されているインターフェイスでイーサネットフロー制御パケットを受信（リッスン）するようにスイッチが設定されているとします。最後に、イーサネットフロー制御をサポートするようにクライアントが設定されていないとします。スイッチには、インターフェイスごとにイーサネットフロー制御の設定があります（ストレージコントローラが接続されているインターフェイスに 1 つの設定、クライアントが接続されているインターフェイスには別の設定）。

トラフィックの停止 / 一時停止：

このシナリオでは、ストレージコントローラからスイッチにポーズフレームを送信できるようになりました。ストレージコントローラが、スイッチの送信速度に応じて情報を処理できないポイントに到達した場合、ストレージコントローラはスイッチにポーズフレーム（ XOFF ）を送信できるようになりました。スイッチは、そのポーズフレームを受信すると、送信を停止することを想定しています。スイッチは、ストレージコントローラに短時間送信する必要があるトラフィックの保留（キュー）を開始する必要があります。これで、ストレージコントローラは以前に受信したデータを処理できるようになります。 

トラフィックの再開：

各ポーズ / XOFF フレームには、特定の期間の送信を停止するようにネイバーデバイスに要求する値（「 Quanta 」と呼ばれる）が含まれています。この時間が経過した場合、または受信側（この例ではストレージコントローラ）から別のイーサネットフロー制御パケットを受信した場合、送信側（この例ではスイッチ）は送信を再開することが想定されています。IEEE 標準に基づいて、スイッチは Quanta の値を評価し、インターフェイスの速度と Quanta の値の組み合わせに基づいて「一時停止」のままにする必要があります。ただし、インターフェイスが「一時停止」のままになると予想される時間は、送信側デバイスのファームウェアによって異なり、このルールに従わない場合があります。

インターフェイスが一時停止していると予測される時間の計算：

ポーズフレーム（ XOFF フレームifstat -a -v）は、コマンドの出力に表示されます。

10Gbpsifstat –a では、このコマンドは「ポーズ」フレームをリストすることがあります。 1Gbps では通常、 XOFF と XON と表示されます。 

ポーズフレームには、要求されたポーズ時間が含まれます。 2 バイトの符号なし整数（ 0 ～ 65535 ）の形式で、「 quanta 」と呼ばれます。この数値は、要求された一時停止時間です。

- それぞれの「 quanta 」は 512 ビット回です。
- 「ビット時間」は、データの送信にかかる秒数として定義されます。インターフェイスは「ビット / 秒」で評価されるため、「ビット時間」はインターフェイスの回線速度の逆です。
            1Gbps （ 1,000,000bps ）インターフェイスの場合、「ビット時間」は 1Gbps

リンクのビットあたり 1/1,000,000,000 秒です。インターフェイスが送信を停止すると予想される最大時間は次のとおりです。

         最大キュータ値 * 512/ （ 10^9 ） = 65535 * 512/1000000000 = 0.03355392 秒 = 33.55 ミリ秒

10Gbps の場合、インターフェイスの送信停止が予想される最大時間は
、 65535 × 512/10^10 = 3.355ms です

プロトコルをサポートする 100Mbps インターフェイスの場合、 100 Mbps インターフェイスは最大 335.5 ミリ秒の間一時停止することが予想されます。

デバイスまたはネットワーク要素は、ポーズフレームを送受信するように設定できます。したがって、 1Gbps インターフェイスでは、ストレージコントローラが「送信」統計情報に XOFF （または一時停止）をリストした場合、ストレージコントローラはスイッチポートに一時停止を指示し、 33.5 ミリ秒までのパケット受信を停止する必要があります。

ストレージコントローラが「受信」統計情報に XOFF （または一時停止）をリストしている場合、スイッチはストレージコントローラにパケットの送信を停止するように指示しています。この場合、ストレージコントローラは最大 33.5 ミリ秒の間、そのインターフェイスでの送信を停止する必要があります。

「 paused 」ポートが、タイマーの期限が切れる前に XON パケットを受信した場合、ポートはただちに送信を再開できます。

潜在的な影響の計算：

例：
-- interface e0b (0 hours, 2 minutes, 21 seconds) --

RECEIVE
Frames/second: 4655 | Bytes/second: 416k | Errors/minute: 0
Discards/minute: 0 | Total frames: 186k | Total bytes: 31954k
Total errors: 0 | Total discards: 0 | Multi/broadcast: 0
No buffers: 0 | Non-primary u/c: 0 | Tag drop: 0
Vlan tag drop: 0 | Vlan untag drop: 0 | CRC errors: 0
Runt frames: 0 | Fragment: 0 | Long frames: 0
Jabber: 0 | Alignment errors: 0 | Bus overruns: 0
Queue overflows: 0 | Xon: 1326 | Xoff: 1326
Jumbo: 0 | Reset: 0 | Reset1: 0
Reset2: 0 | TBI mode: 0 | Pad odd: 0
Pad even: 0
TRANSMIT
Frames/second: 2993 | Bytes/second: 4009k | Errors/minute: 0
Discards/minute: 0 | Total frames: 224k | Total bytes: 285m
Total errors: 0 | Total discards: 0 | Multi/broadcast: 2
Queue overflows: 0 | No buffers: 0 | Frames queued: 0
Buffer coalesces: 0 | MTUs too big: 0 | Max collisions: 0
Single collision: 0 | Multi collisions: 0 | Late collisions: 0
Timeout: 0 | Xon: 0 | Xoff: 0
Jumbo: 0
LINK_INFO
Current state: up | Up to downs: 0 | Auto: on
Status interrupt: 0 | Speed: 1000m | Duplex: full
Flowcontrol: full

収集された統計は、合計 141 秒（ 2 分 21 秒）をカバーします。

• 1326 XOFF フレームを受信しました。
• 各 XOFF フレームは、最大 33.5 ミリ秒の送信を停止している可能性があります。
• 各 XON はストレージ・システム・ポートを解放して、送信を再開します。ただし、 XON が XOFF 後 0.1 ミリ秒、 XOFF 後 1 ミリ秒、 XOFF 後 33.4 ミリ秒のいずれで受信されたかは判断できません。

したがって、ストレージシステムからネットワークへのすべて
の送信が保持される最大 * 潜在時間は、 1326 × 33.5 ms = 44,421 ms = 44.4 秒になります。

「パケットの割合」を考慮

すると、 1326/224000=0.7% のように見えますが、受信したポーズフレームは、送信されたフレームにのみ影響することに注意してください（受信者が送信していた送信を一時的に停止します）。ポートは、スイッチが送信を選択した速度でスイッチからの受信を継続できます。より正確な割合の計算は、 <packets sent>/ <packets that sould have been sent if traffic was not paused > （トラフィックが一時停止されていない場合に送信されるパケット数）でしたただし、トラフィックが一時停止されていない場合に送信されるパケット数を決定する方法はありません。

ポートが送信を妨げている可能性がある時間を考慮すると、その観点は大きく異なります。
さらに関連性

が高い可能性があります。 44.4 秒 /141 秒 = 31% であるため、この 141 秒のインターバルでは、クライアントはストレージシステムのこのポートから応答を受信できませんでした。
もちろん、各「 XOFF 」の直後に「 XON 」が表示されることもあります。この場合、送信トラフィックは短時間だけ停止されます。このことが気づかれないままになっている可能性があります。

したがって、これらの統計情報の場合、 1326 ポーズフレームの影響は、「 none 」 ～ 44.4 秒の範囲になります。フロー制御ポーズフレームは個々のポートを対象とし、動作するため、ポーズフレームは上位プロトコルレイヤに渡されません。PKTT にはポーズフレームは含まれません。スイッチからのほとんどのポートミラートレースには、ポーズフレームは含まれません。「 On the Wire 」パケットキャプチャだけが、確実に真の影響を明らかにします。

ポーズフレームは、ポーズフレームを送信しているデバイスで問題が発生していることを示します。この計算で、ポートが一時停止されている可能性がある最大時間が、データがキャプチャされた時間のかなりの部分であることが確認された場合は、ポーズフレームを送信しているデバイスで問題が発生している理由を調査することを検討してください。

ポーズフレームがトラフィックフローを停止している可能性がある最大時間が、データがキャプチャされた時間のごく一部である場合は、ポーズフレームの存在はそれほど問題になりません。ただし、ポーズフレームが存在する場合は、ポーズフレームを送信しているデバイスである程度の問題が発生していることを示しています。 

プロトコルの本来の目的は、ネイバーがインターフェイスを過負荷にするのに十分な速度で送信している可能性がある場合に、インターフェイスがネイバー（ケーブルのもう一方の端のインターフェイス）を一時停止できるようにすることでした。最初にネイバーインターフェイスを一時停止すると、受信側インターフェイスが過負荷になるのを防ぐことができます。これは状況を改善する場合もありますが、受信側のインターフェイス（およびそのインターフェイスが含まれているノード）がポーズフレーム以外の問題の証拠を登録しないことを意味することもあります。したがって、ポーズフレームが送信される理由を理解する必要がある場合は、イーサネットフロー制御をディセーブルにする必要があります。その後も問題が解決しない場合は、他のカウンタや動作が表示され、過負荷のコンポーネントが NIC 、 PCI バス、またはオペレーティングシステムのいずれにあるかを確認できます。