10Gbpsがつまずいた真の理由とは

　LDPC符号の復号処理は、非常に計算量が多い。符号長をnとすると計算量は2のn乗に比例する。1bitなら2回なのが、2bitなら4回、3bitなら8回……と増え、325bitだと1bitの場合と比べて約6.83×10の97乗倍の計算量になる。さすがにこれは実用にならない。この問題を解決するための研究が進み、「Sum-Product」という復号アルゴリズムを使うことでほぼ符号長に比例する計算量で済むようになったが、それでも325倍になる。

　Sum-Product演算は並列処理が難しいため、ひたすら計算機を高速で動かして1つずつ計算するしか方法がない。ところが2006年当時の半導体製造技術では、これをリーズナブルな消費電力で実現するのが困難だった。2007年には第1世代10GBase-Tの試作品が出現していたが、当時は1ポート当たりのイーサネットコントローラー（イーサネットの制御チップ）の消費電力が10ワットを超えるほどで、現実問題としてブレードサーバやスイッチに内蔵できる消費電力の上限をはるかに超えていた。このような事情からテストなどの目的で少数が流通するにとどまっていた。

　その後、2009年に半導体の微細化で消費電力が大幅に下がり（ポート当たり5ワット前後）、この技術を導入した第2世代製品でマーケットがわずかに広がったものの、まだ十分とはいえなかった。2014年に、半導体プロセスの微細化をさらに進めた第3世代の製品が登場した。特にスイッチがこの第3世代に切り替わったことで次第にラインアップが充実してきた。しかしサーバへの導入がまだ遅れており、2016年から2017年にかけて立ち上がるかどうかという状況にある。この第3世代ではポート当たりの消費電力が3ワット程度に抑えられており、ようやくブレードサーバなどでも導入できるレベルになった。

　消費電力は抑えたものの、もう1つ面倒な問題が残っていた。それは「レイテンシ」（データを送り出してから、それが実際にパケットとして送出されるまでの待ち時間）が大きいことだ。LDPC符号の復号は前述の通り計算量が非常に多い処理なので、いかに半導体プロセスを微細化して高速化と低消費電力化を進めたとしても、一定の処理時間はかかってしまう。一般論になるが、10GbEで光ファイバーを用いた場合や、10GbE向け光トランシーバーモジュール規格「SFP＋」（Small Form-factor Pluggable＋）に準拠した筐体に直接接続できる銅製ケーブル（ダイレクトアタッチケーブル）などを用いた場合、レイテンシは数百ナノ秒のオーダーになる。ところが10GBASE-Tの場合、これが数マイクロ秒必要になる。レイテンシはほぼ10倍だ。

　このレイテンシは、動画配信のパフォーマンス向上やサーバ負荷軽減などに利用するCDN（Contents Deliver Network）やファイルサーバなどでは、あまり問題にはならない。CDNの例で言えば、最初の1枚目の映像が送り出されるまでの時間は数マイクロ秒かかるかもしれないが、その後は連続して送出できるから、視聴する側にとってこれは無視できる範囲といえる。しかし、高性能科学技術計算（HPC：High Performance Computing）や「Map Reduce」をはじめとする並列演算処理を繰り返すような分散処理の場合、データ量そのものは少ないため、レイテンシがボトルネックになりやすい。

　消費電力に関しては、ショートリーチ（30メートル以内の接続）で電力を落とす仕組みや、EEE（Energy Efficient Ethernet：IEEE 802.3azとして標準化した、通信していない状態では電力を遮断する仕組み）などで対策は可能だが、レイテンシを解決するにはLDPC符号の復号処理そのものを、もう一桁高速化する必要がある。しかし高速化を可能にする半導体プロセスの微細化ペースが、このところ急速に鈍化している。消費電力を増やさずに処理能力を一桁高速化できるのは早くて2020年以降、研究が遅れれば、さらにその先という可能性もある。結局のところ、今使える技術では、LDPC符号の問題を解消して高速化を実現するのは望み薄といわざるを得ない。

　以上の理由から、爆発的に増えるデータトラフィックに対処するために必要な超高速ネットワークの実現において、現状の10GBASE-Tは有効な解決策になっていない。ではどうするか。次回はその解決に向けた新しいアプローチを取り上げる。