スポンサードリンク

3種類の接続形態をサポートする「Gen-Z Ver.1.1」、DRAMからのブートは不可(Impress Watch)

スポンサーリンク
スポンサードリンク

3種類の接続形態をサポートする「Gen-Z Ver.1.1」、DRAMからのブートは不可
[元記事]
 「InfiniBandの現在」では、規格としての歴史と現状、今後の動向をまとめて紹介している。大半の読者にとっては「InfiniBandって何?」というところだろうが、僚誌クラウドWatchをご覧になっておられる読者の中には「何で今さら」という方も居られるかもしれない。【この記事に関する別の画像を見る】 そう、InfiniBandという規格は、1999年に作業が始まり、2000年に最初の規格策定が行われたという「えらく古い」規格なのである。
■複数ノード間でプログラムの同期が取れるGen-Zの「MPI」
 2回続けてOpenCAPIの話をしたところだが、今回はGen-Zに話を戻したい。もともとGen-ZがDRAMの接続を当初から考慮していたのは、こちらの記事でも紹介した通りで、実際2016年には”Gen-Z+DDR:A winning combination”なるホワイトペーパーも出されており、この中で複数のDDRメモリをGen-Z経由で接続するというアイディアが示されてる。
 前回紹介した「OpenCAPI 3.1」のOMI(Open Memory Interface)との違いは、メモリコントローラーがInterconnectの手前、つまりプロセッサー側にあるのか、先にある(つまりDRAM側)のかという点だ。OMIではプロセッサー側に、Gen-ZではDRAM側にそれぞれ置かれることになる。
 どちらがいいかは実装次第となるが、OpenCAPIはまだ3.0の段階で、この時点ではそもそもDRAMを扱えなかった。その関係で、OMIのような過渡的なソリューションに頼らざるを得ない状況であり、そうなるとメモリコントローラーはプロセッサー側に置かざるを得なかった、ということがある。
 対するGen-Zでは、そもそもInfiniBandを使ったHPC向けInterconnectの段階で、メモリ共有をすでに実現していた。例えばホストAとホストBをInfiniBandで接続する場合に、ノードAとノードBのそれぞれに共有メモリ領域を設け、片方にデータが書き込まれたら即座に相手側にもそれを反映するというのがその仕組みだ。
 MPIでこれを利用すれば、複数ノード間でプログラムの同期が取れるわけだ。InfiniBandはこの段階で、プロセッサーの先にメモリコントローラーを置く構成をサポートしているわけで、Gen-Zでも当然これを引き継ぐこととなる。
 そんなわけで、CAPI 3.1とはまた違った方式ではあるが、Gen-Zでも同様のことは当然可能だ。コネクタ類も当初からDRAM接続に対応しており(というかOpenCAPIとは異なり、そもそもインターフェースが共通化されているので、別のコネクタを定義する必要がない)、理論上は問題なく利用可能だ。
■Gen-ZはDRAMからのブート不可、OMIの代替にはしない?
 ここで“理論上は”と書いたのは、実装に関して言えばいろいろと制限が付くためだ。その最大のものは、現状のGen-ZのSpecificationでは、Gen-Zの先にあるDRAMだけではブートができないことだ。
 通常CPUは、ブートシーケンスに入るとブートローダーからブートイメージを読み出してメモリへと展開し、その展開されたブートイメージを実行する仕組みになっている。
 ところがGen-Zの場合、メモリへの展開や、展開されたブートイメージの先へのアクセスには、Gen-ZのInterconnectを経由する必要がある。そのためにはGen-Zの制御がブートローダーに格納されている必要があるが、実際はGen-Zの制御は、OSが起動した後にドライバーやHypervisorが行っているため、これをブートローダー側に移植する必要があるわけだ。ただ、現状ではこれが可能な汎用のGen-Zのドライバーは存在しない。
 もちろん、いろいろと回避策はある。Gen-ZのドライバーをUEFIに追加するとか、ブートシーケンスの間だけGen-Zの先にあるDRAMをローカルDRAMに見せかけるようなハードウェア機構、などが考えられる。だが、今のところはそうしたメカニズムを実装した例は見かけないし、Working Groupで検討を行っている可能性はあるにせよ、公式にはそうした話は特に出てきていない。
 そもそもGen-Zは、そのコンセプトからしてCPUの側にローカルのDRAMがあることが前提で、Gen-Zの先のDRAMは共有のワークエリアという扱いだから、OMIの代替というような考え方はしないのかもしれない。
■Gen-Z Ver.1.1では3種類の接続形態をサポート
 そのGen-Zであるが、「Core Specification Version 1.0」が2018年2月に完成し、直後には一般公開も開始されている。その後2019年9月に完成したVersion 1.1も、2020年2月から一般公開が開始されている。このCore Specification 1.1のUpdateをまとめたのが以下の資料だ。
 ただ、このCore Specification 1.1とあわせて公開された「Physical Layer Specification Version 1.1」を見ると、以下の3つが新たに追加されたことが分かる。
・Gen-Z-E-NRZ-PCIe enhanced to support PCIe Gen 5
・Gen-Z-E-PAM4-50G-Fabric
・Gen-Z-E-PAM4-50G-Local
 もともとGen-Zは、InfiniBandをベースとしつつも、さまざまな接続形態をサポートするため、以下の3種類での接続が想定されていた。
・Gen-Z-E-NRZ-25G-Fabric
・Gen-Z-E-NRZ-25G-Local
・Gen-Z-E-NRZ-PCIe Gen 1-4
 このうち「Gen-Z-E-NRZ-25G-Fabric」はInfiniBand EDRを利用した接続、「Gen-Z-E-NRZ-25G-Local」は信号としてはGen-Z-E-NRZ-25G-Fabricと同じながら超近距離(同じ基板上か、長くてもバックプレーン経由程度)を想定した接続、そして「Gen-Z-E-NRZ-PCIe Gen 1-4」は文字通りPCIe Gen 1-4のPHYを利用した接続である。
 あくまでも利用するのはPHYだけであり、PCI ExpressのPhysical Layer Logical Block SpecificationとElectrical Sub-block、およびPower Managementの各Specificationには準拠するが、上位のLink LayerやTransaction Layerは利用しておらず、あくまでも物理的に同じ配線(とPHY)を共有するだけだ。
 これがVersion 1.1となると、見ても分かるように、PCI Express Gen5のPHYとInfiniBand HDR、および同じ信号レートを持つローカル接続の3種類が追加でサポートされたわけだ。これらは、言うまでもなくInfiniBand HDRの出荷開始に合わせ、これを利用できるように改定したもので、その意味では順当なアップデートだろう。
■Gen-Z Ver.1.1の仕様から判明したInfiniBand HDRの信号スペック
 余談だが、このSpecificationのおかげで、InfiniBand HDRの信号スペックも判明した。もともとIBTAのInfiniband Specificationは、現時点でもRelease 1.3.1までしか公開されておらず、ここではInfiniBand EDRまでは定義されているものの、InfiniBand HDRについては不明なままだった。ところが、Gen-Z-E-PAM4-50G-Fabric Specificationによれば、以下のような数字が定義されている。
・信号速度はレーンあたり53.125GT/sec
・変調はPAM4
・FEC(Forward Error Correction)にはPhit FEC 288(260bitのデータを288bitで送信)とPhit FET 320(260bitのデータを320bitで送信)の2種類があり、実行転送速度は前者が47.222GbpsながらBER(Bit Error Rate)は10^-9、後者は42.5GbpsとなるがBERは10^-15に改善される。
・COM(Channel Operating Margin)は13.2814GHzで20dB未満
 ちなみに、Gen-Z-E-NRZ-25G-Fabric Specification(InfiniBand EDR相当)の場合は以下とされている。
・信号速度はレーンあたり25.78125GT/s
・64b/66bエンコードで実効データレートは25Gbps
・BERは10^-12以下
・COMは12.89GHzで30dB未満
 これは、「InfiniBand Architecture Specification Volume 2 Release 1.3.1」に定義されたInfiniBand EDRのスペックにも合致するので、おそらくGen-Z-E-PAM4-50G-FabricのものがInfiniBand HDRと同等と思われる。これを見ると、単純にPAM4を噛ましただけでは難しいだろうとは思っていたが、結構なFECを掛けないとBERがかなり悪くなることが推測できる。
 BERが10^-9というのは、要するに1Gbit送ると1bit化けるということで、Phit FEC 288を使うと毎秒50bit分は化ける計算になる。これがPhit FEC 320だと1000Tbitあたり1bit化けるレベルで、20000秒あたり1bitの計算になる。通常はBERは10^-12あたりを狙う(これだと1000Gbitあたり1bitだから、20秒に1回程度、1bit化ける)と思うのだが、うまく10^-12あたりに収束させるFECがなかったのかもしれない。

スポンサードリンク
スポンサーリンク

シェアする

  • このエントリーをはてなブックマークに追加

フォローする

スポンサーリンク