FCTEL オリジナル技術記事 · FCTEL技術チーム
初公開：2026-10-05 · 最終更新：2026-10-05
ポート使用率のグラフは低いままなのに、マシンビジョンの画像でときどきフレームが欠落し、PLCの応答が突然遅くなることがあります。考えられる原因の一つがマイクロバーストです。これは、短い時間内に複数の機器が同じ出力に向けて送信する現象です。スイッチはすべてを即座に送信できないため、フレームを一時的に保存する必要があります。バッファ領域が不足すると、廃棄につながることがあります。本記事では、受信、キューイング、スケジューリング、送信の流れを追い、一般的な仕組み、説明用の計算、FCTEL製品について明示的に文書化されている機能を区別します。
詳細は元の画像を開いてご確認ください。横方向にスクロールすると、図中のラベルを原寸で読めます。
1．複数のギガビット入力が単一の出力で競合する理由
スイッチはEthernetフレームを受信すると、適用される転送テーブルとポリシーに基づいて出力を決定します。複数の入力で同時に受信することはできますが、通常の単一物理出力は、ある送信方向について、その回線速度でフレームを順次送信します。2台のカメラが同じ解析サーバーに画像を送信する場合、両方の接続がギガビット動作でネゴシエーションされていても、サーバーにつながる単一のギガビットスイッチポートで競合することがあります。入力を追加しても、その出力の容量は増えません。
バッファはフレームデータを保存する領域です。一方、キューは送信待ちデータと、それを処理するための管理上の関係を指します。両者は関連していますが、同じ意味ではありません。スイッチングチップは、共有ストレージ、ポートへの割り当て、複数のトラフィックキューを使用することがあります。その割り当て規則によって、その時点で出力が利用できる領域の量が決まります。製品の総バッファ容量の仕様は、各ポートがその容量を専有できることを意味せず、特定のアプリケーションの待ち時間を直接示すものでもありません。
ここで扱うのは、出力負荷が一時的に処理容量を超える状況です。これは、ループによってフレームが絶えず複製される状況や、干渉によって銅線リンク上のフレームが破損する状況とは異なります。あらゆる損失をケーブルやスイッチの故障のせいにする前に、輻輳の発生箇所とトラフィックの方向を確認してください。
詳細は元の画像を開いてご確認ください。横方向にスクロールすると、図中のラベルを原寸で読めます。
2．マイクロバーストが平均使用率グラフに現れない仕組み
平均レートは、送信ビット数を測定時間で割った値です。1秒間の測定では、1ミリ秒のバーストは残りのアイドル時間によって平均化され、目立たなくなります。測定時間が長いほど、ピークは隠れやすくなります。同期したカメラトリガー、ブロック単位のアップロード、機器からの同時報告によって、トラフィックが特定の時間に集中することがあります。すべての機器に適用できる単一のマイクロバースト継続時間のしきい値はありません。重要なのは、瞬間的な流入レートが出力の処理速度を上回るという条件です。
理想化した計算を考えます。初期状態で空のキューに対し、2つの入力から合計2 Gbit/sで1 msの間データが到着し、出力は1 Gbit/sで送信するとします。その差は1 Gbit/sです。この差に時間を掛け、8で割ると、送信待ちデータは125,000バイト、約125 kBとなります。入力が停止した後、これを1 Gbit/sで送信し終えるまでには、さらに約1 msかかります。三角形のキュー使用量グラフは、十分なバッファ容量があると仮定し、プリアンブル、フレーム間ギャップ、その他のトラフィックを無視しています。
その1秒間にこのバーストしか発生しなければ、到着データの合計は250 kBで、平均入力レートはわずか約2 Mbit/sです。それでも、1ミリ秒の到着期間中には125 kB分のバッファが必要です。利用可能な割り当て容量がこれより小さければ、廃棄はより早く始まり、使用量曲線は容量上限で頭打ちになります。したがって、平均使用率が低いことは、瞬間的な輻輳がない証拠にも、出力廃棄を否定する根拠にもなりません。
3．バッファリングはバーストを吸収すると同時に待ち時間を増やす
出力キュー内のフレームは、その前にある処理が完了するまで待つ必要があります。キュー内のバイト数に8を掛け、出力レートで割ると、処理時間を概算できます。実際の動作は、フレーム境界、リンクのオーバーヘッド、スケジューリングにも依存します。バッファを大きくすると、より長い短時間バーストを吸収できますが、フレームの待ち時間も長くなる可能性があります。入力が出力を持続的に上回る場合、有限のバッファはいずれ満杯になります。保存領域を追加しても、持続的な容量不足は解消しません。
保存領域を使い切ったときの動作は、実装とポリシーによって異なります。一般的なテールドロップでは、キューが満杯になると新たに到着したフレームを拒否しますが、別のしきい値、優先度規則、早期廃棄機構が適用される場合もあります。あるチップの方式が、すべての産業用スイッチの標準だと考えないでください。TCPは確認応答と再送によってデータを回復できる場合がありますが、その間、アプリケーションには追加の待ち時間が生じます。UDPや一部のリアルタイムアプリケーションでは、独自の損失処理やタイムアウト処理が必要です。
リンク層フロー制御にも限界があります。有効になっているか、対向機器が応答するか、どのトラフィックに影響するか、他のアプリケーションにもブロッキングが波及するかを確認してください。フロー制御の有効化は、制御ネットワークの容量計画の代わりにはなりません。検証なしに、PAUSEフレームがPLCの期限を保証すると考えることはできません。
詳細は元の画像を開いてご確認ください。横方向にスクロールすると、図中のラベルを原寸で読めます。
4．QoSがゼロ遅延を保証しない理由
QoSは一般に、ポート、IEEE 802.1p優先度、IP DSCPなどの条件でトラフィックを分類し、内部キューに割り当て、スケジューラによって次のフレームを選択します。マーキングは分類情報です。経路全体で対応するマッピングとスケジューリングが行われなければ、マーキングされたフレームが必ず優先的に処理されるとは限りません。厳密優先スケジューリングと重み付きスケジューリングでは、公平性の特性が異なります。対象のモデルとファームウェアについて、アルゴリズム、キュー数、レート制御を確認してください。
通常の非プリエンプティブ送信では、出力が通常フレームの送信を開始した後に、短い制御フレームが高優先度キューに入ることがあります。スケジューラは通常、そのフレームの送信完了を待ってから制御フレームを選択します。1,518バイトのフレームを100 Mbit/sでシリアル送信するには、プリアンブルとフレーム間ギャップを除いて約121.44マイクロ秒かかります。1 Gbit/sでは、同じフレームのみの計算で約12.144マイクロ秒となります。これらは説明用の計算であり、機器の遅延保証値ではありません。
専用のEthernetフレームプリエンプションには、対応する機能、設定、対向機器の協調動作が必要です。QoS対応という記載だけから、プリエンプションにも対応していると判断することはできません。高優先度の制御トラフィックであっても、他の制御トラフィックと競合する可能性があり、他の処理段階でも待ち時間が加わります。決定論的な設計では、まずアプリケーションの最大許容遅延とピーク負荷を把握し、各区間を検証するとともに、すべてのフレームを最高優先度に設定することを避けます。
5．輻輳と物理リンクエラーを区別する
まず、ポート速度とデュプレックス状態、入力および出力のバイトカウンタ、廃棄カウンタ、CRCまたはFCSエラーカウンタを記録して保存してください。各カウンタの方向、単位、更新間隔を確認します。出力廃棄の増加は、出力リソースやポリシーに原因があることを示す場合が多く、CRCエラーがある場合は受信リンクの健全性を調べる必要があります。両方が同時に発生することもあります。1つのカウンタだけで、他のあらゆる原因を除外することはできません。アプリケーションのフレーム欠落やタイムアウトの発生時刻と照合してください。
観測の時間分解能を高め、対応している場合はキュー使用量、ピーク、廃棄の分類を調べます。機器にこれらの指標がない場合は、試験環境でトラフィックを制御し、送信元が1台の場合、2台が同期して送信する場合、送信タイミングをずらした場合を比較してください。同じ出力でのカウンタ増分と、アプリケーションの応答を測定します。ミラーポートにも固有の容量上限があります。ミラーリングされたキャプチャ経路での損失が、そのままアプリケーション向け出力での損失を意味するわけではありません。
6．FCTEL機器の実践的な受入試験方法
FCTELの公式資料では、10ギガビット光ポート4基とギガビット電気ポート8基を備えたDINレール取り付け型の管理機能付きレイヤー3産業用スイッチについて、ストアアンドフォワード動作、IEEE 802.1pおよびDSCPによる優先キュー管理、ポート統計が記載されています。これらの文書化された機能は、設計と受入試験を検討する際の製品上の前提となります。ただし、特定のマイクロバースト監視機能、フレームプリエンプション、所定のポート別バッファ割り当てへの対応を示すものではありません。対応するマニュアルとファームウェアに照らして、設定と利用可能な統計を確認してください。
出力容量の増強、上流の瞬間レートの低減、送信タイミングの分散、適切なキュースケジューリングを検討する前に、実際のボトルネックを特定してください。リンクアグリゲーションは、単一のアプリケーションフローがすべてのメンバーリンクを同時に使用できることを保証しません。ハッシュ方式とトラフィックの分散状況を確認してください。変更後は同じピーク負荷試験を繰り返し、廃棄、待ち時間、アプリケーションデータの完全性、回復を記録します。制御アプリケーションの許容範囲内で改善を実証することで、平均使用率が低い状況での間欠的な障害を理解できるようになります。
技術参考資料： Cisco：マイクロバーストの仕組みとプラットフォーム固有の監視。関連するFCTEL資料： 技術記事 および 産業用スイッチ製品資料（中国語）.
