会社案内 (近況 2008/07)
先月 翌月今後の作業:
こんなとこかな。あとは多くのユーザに使ってもらってダメ出ししてもらえる ように広報活動か。
英語版の Web やらユーザガイドやら利用許諾やらを作った。英語圏の開発者 はここらへんの作業が不要なわけで、その点に関して我々はけっこう不利だよなー。
Google AdWords で国外向け広告も発信し始めた。表示回数が国内に比べて 1 桁以上多い。そりゃそうか。
DMA write のチューニングをほぼ完了した。チューニング作業はそれなりに大 変だったが、それでも 4 日で終わって、性能が劇的に向上した。しかし長い 転送でデータがおかしくなるというバグがあり、再現性が無いので原因がなか なかわからなかった。結局 flow control credit を上流に伝達するところの 制御が間違っていて、送信を待たなくてはならない時に待たずに送ってしまっ ていた。そのせいでホスト側の flow control バッファが溢れて転送データの 一部が消失してしまっていた。これが分かるまでにに 1 週間を費した。
チューニングによりほぼ理論限界の性能が出るようになった。つまりTLP の合 間に idle cycle を全く挟まず送出できるようになった。データサイズ 32k byte の場合に P 社 (特に社名を伏す) コアと比べて 25% くらい速い。けっ こーすごいと思うのだが世間的にはどうか?
chipset:E5400, max payload size = 128 byte x8 DMAW 性能: # hib[0] DMA write (host <- HIB) size: 1024 DMA write: 1.477223 sec 541.556721 MB/s size: 2048 DMA write: 0.992979 sec 805.656474 MB/s size: 4096 DMA write: 0.760005 sec 1052.624658 MB/s size: 8192 DMA write: 0.641797 sec 1246.499934 MB/s size: 16384 DMA write: 0.581242 sec 1376.362829 MB/s size: 32768 DMA write: 0.551060 sec 1451.747643 MB/s x4 DMAW 性能: # hib[0] DMA write (host <- HIB) size: 1024 DMA write: 1.902337 sec 420.535357 MB/s size: 2048 DMA write: 1.441879 sec 554.831564 MB/s size: 4096 DMA write: 1.213423 sec 659.291930 MB/s size: 8192 DMA write: 1.097494 sec 728.933445 MB/s size: 16384 DMA write: 1.037838 sec 770.833226 MB/s size: 32768 DMA write: 1.006869 sec 794.542228 MB/s
データサイズ 32k byte の場合に 1.4GB/s 以上出ている。ピーク 2.0GB/s に 対して 70%。これ以上転送効率をあげるには max payload size が 256 byte 以上の chipset を使うしかないだろう。max payload が 256 byte あれば 1.7 GB/s (83%)、512 byte なら 1.8GB/s (88%) くらい出るはず。
プレスリリース。反応あるかな。ないだろうな。問い合わせが2〜3件もあれば 大成功、ってとこか。
リリースに向け、コアのソースを整理して、ソフトウェア、マニュアルなどを つけたパッケージを作りつつある。自作コアの名前は GPCIe に決定。G は何 かの略というわけではない。「当社製品の商品名はすべて G で始まることに しよう」という、言った本人もすっかり忘れていたしゃちょーの言葉に従った 命名。
せっかくなのでプレスリリースをすることにした。手続きを代行業者に依頼した。
PIO write が理論値よりも遅いので原因を調べた。
理論値 : ホストの main memory 上の write-combining された領域に対して PIO write を発行する場合、各 TLP は 64 byte の payload を持つはず。こ れにヘッダや LCRC などを追加すると、1 個の TLP の大きさは 84 btye。こ れを 16byte/clk で受信するので、TLP 1 個の受信には 6 clk かかる。6 clk (@125MHz) で 64byte 受信する場合の転送速度は 1.33GB/s。
実測値 : 960MB/s しか出ていない。状況を詳しく観測したところ、ホストか らは 64 byte の payload を持った TLP がびっしりつながって届いており、 コア側が credit 不足によりウェイトをかけていることが判明した。受信した TLP を Application 層側に読み出す速度が足りていない。6clk に 1 個の TLP が届いているのに、それを読み出すのに 8clk かかっている。
Transaction 層から Application 層への読み出しを管理しているステートマ シンに若干無理をいって頑張ってもらい、6clk で読み出せるようにしたところ、 理論値に近い速度が出るようになった:
x8 PIOW 性能: # hib[0] PIO write (host -> HIB) size: 64 DMA read: 1.271717 sec 629.070741 MB/s size: 128 DMA read: 0.872109 sec 917.316595 MB/s size: 256 DMA read: 0.675987 sec 1183.454702 MB/s size: 512 DMA read: 0.638331 sec 1253.268414 MB/s size: 1024 DMA read: 0.619478 sec 1291.409891 MB/s size: 2048 DMA read: 0.619503 sec 1291.357705 MB/s size: 4096 DMA read: 0.619569 sec 1291.220055 MB/s size: 8192 DMA read: 0.619512 sec 1291.339317 MB/s size: 16384 DMA read: 0.619499 sec 1291.366154 MB/s x4 PIOW 性能: # hib[0] PIO write (host -> HIB) size: 64 DMA read: 1.404858 sec 569.452525 MB/s size: 128 DMA read: 1.276554 sec 626.687224 MB/s size: 256 DMA read: 1.188550 sec 673.088926 MB/s size: 512 DMA read: 1.137777 sec 703.125572 MB/s size: 1024 DMA read: 1.121448 sec 713.363412 MB/s size: 2048 DMA read: 1.121450 sec 713.362047 MB/s size: 4096 DMA read: 1.122619 sec 712.619385 MB/s size: 8192 DMA read: 1.122715 sec 712.558399 MB/s size: 16384 DMA read: 1.122694 sec 712.571715 MB/s
DMA write にも同様の問題があるが、回路修正がかなり難しいので当面保留。
x8 コアをしゃちょーにも試してもらったところ、このコアはホストによって 認識されたりされなかったり、挙動が不安定だということが分かってきた。
で、原因を調べてみた: 認識されない時にはリンクトレーニングがうまくいっ ていない。LTSSM が config.complete で止まってしまう。ここはホスト側が コアの Tx から届いた信号の lane-to-lane deskew を行うべきステートなの だが、skew が大きすぎるせいでいつまでたっても deskew できず、このステー トを抜けられないのではないだろうか。
x1 alt2gxb を 8 個束ねて使うことに無理があ る気がするので、構成を変えてx4 alt2gxb 2 個にしてみた。先月試した時に はこの構成ではエラーが出て合成できなかったが、.qsf に GXB_GROUP_DRIVER と GXB_GROUP の指定を加えたら合成できた。この変更後は x8 でも安定して 認識されるようになったような気がするがどうか?