14GT/secの「InfiniBand FDR」と25GT/secの「InfiniBand EDR」、64b66b採用によるエラー増には「FEC」で対応

「InfiniBand Architecture Release 1.3」が2012年11月にリリース

　前回少し触れた「InfiniBand FDR」が実際に規定されたのは、2012年11月6日にリリースされた「InfiniBand Architecture Release 1.3」となる。このため、2011年6月にリリースされた「ConnectX-3」は、Release 1.3のDraftをベースにしていた。

　Wi-Fiの新規格対応を彷彿させる風景ではあるが、そもそも仕様策定にMellanoxががっちり噛んでいる上に、現実問題としてMellanoxの製品の市場占有率が5割を超え、しかもHCAとスイッチの両方を提供していた。

　そんな状況だから、マルチベンダー環境での相互接続性などで問題が出る可能性はもちろんあるにせよ、MellanoxのHCAとスイッチ、あるいはMellanoxのスイッチ用チップを用いた別メーカー製スイッチなどを組み合わせている限り、ユーザーにはあまり問題は起きなかったと思われる。

多数の通信環境を効率化、送受信のキューを対にして管理する「XRC」

　さてこの2012年に出たInfiniBand Architecture Release 1.3には、ほかに修正などは多数存在するものの、新たな機能拡張は以下の2点となる。

• 「InfiniBand FDR」および「InfiniBand EDR」という新しい信号伝送規格
• 「XRC」と呼ばれる新しい伝送メカニズム

　まずXRCの方を先に説明しておこう。InfiniBandでは「QP（Queue Pair）」という概念が存在する。これは送信側のキュー（Send Work Queue）と受信側のキュー（Receive Work Queue）を対にして管理するというものだ。

　このQPは送受信ごとに生成されるので、InfiniBandのネットワーク内で多数の通信が同時に行われる場合、膨大な数のQPが生成されることになる。そこで複数のQPをまとめて代行できるような通信方式として、「Extended Reliable Connection（XRC）」がRelease 1.3で定義された。これを利用することで、多数の通信が並行して行われるような環境でも、オーバーヘッドの少ない効率的な通信が可能になる、というものだ。

「InfiniBand FDR/EDR」では帯域増加に技術的な壁が

　さて、本題はFDRおよびEDRである。これまでInfiniBandは、2.5GT/s→5GT/s→10GT/sと倍々ゲームで帯域を増やしてきたが、さすがにこのあたりで技術の壁に突き当たった。

　この点については、InfiniBandだけでなくPCI ExpressやSerial ATAなどでも同様だ。PCI Expressは2.5GT/s（2003年）→5GT/s（2007年）の後、10GT/sは難しいということで8GT/s（2010年）までは順調に推移したが、その次に16GT/sの標準化が完了したのは2017年のことだった。Serial ATAも1.5GT/s（2003年）→3GT/s（2004年）→6GT/s（2009年）と、ここまでは順調だったものの、12GT/sに関しては、安価に実現できる見込みが立たないとして放棄。より高コストが許容できるSAS（Serial Attached SCSI）に関しては2013年に標準化が終わり、2017年には22.5GT/s（公称24GT/s）の「SAS-4」が標準化された。やはり10GT/secを超えると、どうしても時間がかかるにようになる。

　InfiniBandは幸いにも、PCI Expressよりは制約が少なかった。PCI Expressの場合、標準化された（＝特定のベンダーが特許を取っているようなものではない）技術で16GT/secを実現する、という目標を掲げており、これもあって当初は「そもそも技術的に実現できない」といった状況に陥っていた。

　だが、InfiniBandの場合は、ネットワークとかサーバーのバックプレーンなどの技術に長けた企業が集まって標準化を行ったことと、特許で保護された技術の利用も許したことで、比較的早期に標準化が完了したようだ。

　とはいえ、技術的に大変な部分はいろいろあったようだ。Volume 2のChapter 6が、"High Speed Electrical Interfaces"として実際に速度を定義しているのだが、その6.1.1にBackground and Reference Materialとして、Howard Johnson氏とMartin Graham氏の共著『High-Speed Digital Design: A Handbook of Black Magic』、およびWilliam J. Dally氏とJohn W. Poulton氏の共著『Digital Systems Engineering』の2冊が「仕様を理解する上で役に立つ文献」として示されているあたり、その苦労がしのばれる。

　余談ついでに書いておけば、この2冊は特にHigh Speed Signalingの教科書というかバイブルとして有名なものだが、筆者が知る限り残念ながら翻訳版は存在しない。昨今だとStephen H. HallとHoward L. Heck氏の共著「Advanced Signal Integrity for High-Speed Digital Designs』がむしろ教科書として広く利用されている（こちらは日本語版がある）かと思うが、原著の出版が2009年と比較的新しいためか、残念ながらこちらは入っていない。

　さらに余談となるが、冒頭のBlack Magicの著者であるHoward Johnson氏は、Teledyne Lecroyのウェブサイトで"Fundamentals of Signal Integrity"という講座を開設しており、このNo.8までは日本語サイトで翻訳が出ている（無料だが要登録）。だが、本国の方がこの講座を"Teledyne LeCroy Signal Integrity Academy"に改編してしまっており、気軽に読めなくなったのはちょっと残念である。

"Fundamentals of Signal Integrity"の日本語版「シグナル・インテグリティの基本」のウェブサイト

14GT/secのInfiniBand FDR、25GT/secのInfiniBand EDR、エンコードも8b10bから64b66bへ

　脱線し過ぎたので話を元に戻そう。このRelease 1.3では、データレートが14.0625GT/secの「InfiniBand FDR」、同じく25.78125GT/secの「InfiniBand EDR」の2つが新たに追加された。

出典はInfiniBand Architecture Release 1.3 Volume 2のTable 39

　14GT/secと25GT/secという数値がどこから出てきたのかは、少し調べたものの発見できなかった。おそらく2011～2012年の検討段階で、無理なく実現できるのが14GT/sec、頑張ればという目途が立ったのが25GT/secというあたりではないかと思う。ちなみにFDRの正式な名称は"Fourteen Gigabit per second Data Rate"、EDRは"Extended Data Rate"なのだが、FDRがあまりにも取って付けたような名前なのが気になるところだ。

　さて、14GT/secだとInfiniBand QDRから40％程度の帯域アップでしかないから、やや見劣りする。それもあってか、エンコードも従来の8b10bから64b66bへと変更されている。前にも触れたが8b10bでは、PCI Expressなどと同じく、クロック信号や制御パラメータなどをデータに埋め込むことで、1本の信号線でデータとクロック、制御信号を伝達できるのが長所だ。

　ただし、10bit分のシンボルを送っても、そのうちデータは8bitしか格納できないので、1レーンあたりの実効転送速度は、InfiniBand QDRの場合で10GT/s÷10bit×8bit＝1GB/secとなる。対してInfiniBand FDRでは14.0625GT/sec÷66bit×64bit≒1.7GB/secなので、70％ほど帯域が増えることになる。ちなみに、PCI Express Gen4以降では同様に128b130bのエンコードを採用しており、こちらも実効転送効率が高く取れる仕組みと言える。

64b66bでは制御信号の待ち時間が4.7倍に「FEC」の追加でエラーの増加に対応

　こうした高効率のエンコードを最初から採用しなかった理由は、8b10bでは10bit分を送ればクロック信号や制御信号を取り出せるのに対し、64b66bではこれを取り出すのに66bit分送る必要があることに起因している。一方で転送速度は1.4倍になっているので、所要時間は4.7倍ほどに増える計算となる。要するに、制御信号を転送しても、それを相手が制御信号だと認識できるまでの待ち時間が4.7倍になってしまうわけだ（同様にPCI Express Gen3の128b130bでは、Gen2との比較で待ち時間は8.1倍ほどに長くなる）。

　この待ち時間の長さにより、初期化の時間が長くなる、モード推移時の反応が遅くなるといった弊害が出るほか、回路規模がどうしても大きくなるという問題もある。このあたりを嫌って8b10bを採用していたが、より高速に、という声に押され、止むなくこうした長めのエンコードに切り替えたかたちである。

　ちなみに、データレートを引き上げると、当然エラーも増える。そもそも10GT/sの時点でも伝送特性の面でもかなり厳しいものがあり、これを14GT/sに引き上げればさらに厳しくなるので、その分エラーがさらに増えてしまう。

　InfiniBand EDR/FDRではこれに対応するため、「FEC（Forward Error Correction）」が追加された。データは64bit単位に分割され、これを66bitのシンボルに変換するが、それを送り出す前に誤り訂正用の冗長ビットを付加する。受信側は受け取ったらパケットの正当性を判断し、エラーを検出したら誤り訂正を掛けることでエラーを回復できるというものだ。

出典はInfiniBand Architecture Release 1.3 Volume 2のFigure 19

　InfiniBand FDR/EDRの場合、66bitのシンボルのうち2bitのSync Header bitを1bitの冗長ビットに変換（この時点でシンボルは65bit長になる）した上で、このシンボルを32個まとめ、さらに32bitのパリティを付加している。

　分かりにくいかもしれないが、2080bit分のシンボルに対して、実際には2112bitを送信するかたちになるわけだ。受信側はこの2112bitから2080bitのシンボルを復元し、ここから元のデータを64b66bデコードで取り出すという仕組みである。

　これにより、効率はさらに落ちる（2080÷2112≒98.5％）から、実行転送速度は1.68GB/sec程度になるし、1回のFECが32パケット単位で処理されるので、先に挙げた待ち時間もさらに長くなる。その代わり軽微なエラーであれば再送を行わなくても受信側で回復できるようになるので、このあたりのメリットとデメリットを勘案しての採用となったわけだ。