beyond the PCI express

・Refreshed IBM Power Linux Systems Add NVLink

ですよねー。諸行無常の響きアリ。一度頭の中をリセットする時期かも知れないな。

内製最強説

・何度かマ板で上がったネタ「内製最強説」

元々R&Dだったのでどちらかと言えば社内ひきこもり環境には恵まれていた。とはいえ数年ほど受託で仕事をしていた時もあるし、いわゆる客先で作業をしていた頃もある。

なんとかソフトにある協力会社（この呼び名もどうなんだか。素直に下請で良いじゃないか）押し込みフロアの机は大層小さくそれはそれは貧弱であったが、社員達の机はさらに小さいのであった。え？マジ？が最初に抱いた感想。オレが新卒で入った会社の方がはるかに優雅だった。日本で誰もが知っているような会社の社員の待遇がこれなのだから、ICTエンジニアの未来も暗くなるのも当然。

だが日本ではこれが現実。

よって少しでもICTエンジニアの地位と待遇の改善（いやまー日本全体で見たら給与はマシなの知ってるけどさ）要求するニダ！

その為には内製じゃなかろうか。方法論としてよりも。もはや現代ビジネスとICTは両輪であるという意識付けが大事で、彼ら（社内ITチーム）はコストセンターじゃなくて無くてはならないパートナーなんだ！というユーザー（主に営業チーム）意識が大切。

といつも営業達から苛められている社内ITチームの友人を見て思いました。でも残業代はエグいとも思いました。そう考えるとやっぱコストセンターだなとボクも思いました。

うーんでもやっぱりボクも内製派です。自分達で作った方が楽しいもん。そんな人材採れるのかよ？というのが一番大きな問題かな。

RDMA

・SSDのリモートDMAを実現する「NVMe Over Fabrics」


当時僕たちが夢見たRDMA。あとでちょっと書く。

追記。

人はなぜかblock deviceをネットワーク越しにアクセスしたくなる。オレも15年くらい前に自前のnetwork block deviceを実装したことがある。そこでRDMAという概念を知り、ああこれは素晴らしいね！と思うのだが…。

この辺りを斜め読み。

・NVM Express Over Fabrics - openfabrics
・NVMe over Fabrics - SNIA
・NVMe Over Fabrics Flash Memory Summit
・NVM Express over Fabrics - chelsio
・NVMe over 40GbE iWARP RDMA

生きていたのか！iWarp！net effectの恨み、まだオレは忘れていないぞIntelめ。ごめん書かずにはいられなかった。

うーん、結局iSCSIの代替かーという印象。というか今の会社に入ってからこのアーキひたすら考えてたわーそんなオレすげーではなく、いやこれ単にRDMA言いたいだけなんじゃないの、と。

突き詰めると、DASとの差別化が難しくなる。単一ホスト下でPCIe（でもなんでも良いけど）をファブリックで伸ばして単純にストレージデバイスとして見せた方がどう考えても楽。ハードの割り込みも直で取れるし。特に細工しなくてもBIOS（UEFI）がデバイスを見つけてくれる。

資料の中には割り込みもサポート、と書いてあるのもあるけれど、ネットワークで割り込みを中継したら低レイテンシとは口が裂けても言えないだろう。ネットワークは非同期なのが良いところ（しかも無責任にね）で、そこまで同期的に動くならそれはもうバスだ。

いやPCIe extendedな距離ではなくて、もっと遠距離に飛ばしたいんだというのであれば理解できる。某N社のexpetherという手もあるけれどね。でもそれだったらOver EtherでOK。Over Fabricと書く以上、遠距離ではないだろう。

ストレージを集中管理したいというニーズはある。ただRDMAというものが恐ろしく複数ホストからのシェアリングに向いていない。当然だがそのセクタないしアドレスを特定のホストが占有する。占有する為に、予めMPI同様にそのアドレスをregisterする必要がある。ROなら問題ないけど、だったらfile systemレベルを選択したくなるし、それはもうNASの世界だ。

うーん、どうやってもoffloadにしかならない。それもかなり古いアーキの。

だから個人的には抽象レベルを一段引き上げるべきだと思う。逆にまずRDMAから離れるべき。remoteのNVMeホストは配下デバイスを全て仮想アドレス（+α）で持ち、それに対してのDMAを実行する。つまりIOMMUのように仮想アドレスと実アドレスを変換するような機能をネットワーク越しに提供すればいい。そのアドレス群に対してクライアントはmulti queueからScatter/Gatherすれば今っぽいと思うんだけどな。あ、今思いついたこれをRemote SGと呼ぼう。

あ、でもそれなんてNetwork MMU？(IBMがそんなものを作っていた気が)

奥さん、もう12月ですってよ

・Advent Calendar 2015

去年はすごい辛かったので今年は書かないぞー！ジョジョ！

というか今年はあんまりネタが無いよね。台北に引きこもっていたから。SC15に行きたかったけど、予算も時間も無いので安藤壽茂さんのレポートを読んで行った気になるプレイ中。

・Hisa Ando
・ 安藤壽茂

memo

・MS、ブロックチェーンサービス「Ethereum Blockchain as a Service」を発表

・スラド

仕事柄いろいろこの方面の話を聞いており、ちょっと気になる感じ。そういえばオレも数年前に分散型バックエンドDBの原型みたいなの作ったなー。あまりにLayerが低すぎて失敗したけど。あそこは逆に上に行くべきだったのだけど、上に行くと当時は興味の方向性が合わなかった。blockchain 2.0とかも始まって来ているので、この分野がもっと伸びると楽しいな。

winドライバ証明書のはなし

・Windows10では個人でのドライバ開発が不可能に？

・準備OK？　EVコードサイニング証明書の現状とその実際

スラドより。ZYNQあたりのFPGAで遊んでいると意外と困るやも知れぬ。DDKが無料配布になってからMSもオープン化の波に乗り始めたなーという感想を持っていたものの、OS自体のセキュリティを考えると致し方ないのかな。たぶんデバッグモードではインストールできるとは思うけれど、常用するわけにはいかないだろう。

うーん、jungoが儲かりますなあ。Xilinxが出しているサンプルアプリケーションのドライバがjungo製でソースが公開されていない為、VerilogソースからLinuxドライバを書くはめになって、Verilogのバグをデバドラで吸収してたりすると地獄を見るパターンを思い出した。

Linux IPC

久しぶりにLinuxのプロセス間通信を見直す機会が。ガシガシその辺りを書いていたのも、もう15年くらい前なのでさぞかし状況は一変しているのだろうと思いきやそうでもなかった。まぁ普段フレームワーク上で作業している分には縁遠い話ではあるけど、やっぱりDistributedな世界だと基本だよねーと適当に検索していたら比較的新しい資料を見つけた。参考になります。

・An introduction to Linux IPC

AMD FX-9590

最近はx86系のMBを作る仕事もあまりなく、あっても利益がでるような構造にもなっていないので、お断りすることが多い。それかSuperMicoroやAxiomtek辺りの製品リストを見せてこれらのどれかに合わせるのを薦めている。

というわけで、最近のCPU事情にすっかり疎くなった。ハードが雲の向こうに行ってしまったのもあるし、会社の予算もすっからかん。CPUリストとにらめっこしたのは、2年半くらい前に自前で組んだのが最後だったように思う。

そんな中、AMDのFX-9590を評価する機会を得た。わーい！4.7Ghzの8コア220Wだぜ～！どう考えても空冷じゃ無理！こんなに熱いのだからきっと爆速に違いない！

結果。

遅い。死ぬほど遅い。何か間違えているのではなかろうかと思うくらい遅い。あまりに信じられない数値に思わずぐぐる。

・Single Thread Performance

スコア1723、Rank253。うっそ～ん。8コアなのでトータルのパフォーマンス自体は悪くないのだが、如何せんコア単体が遅すぎる。

2年半前、オレが自前で組んだ時に使ったのがi5-3570K、3.4Ghzでスコア2030、88位。ちなみに1位のi7-4790Kが2530。確かにCore2以降はIntelの独壇場だとは思っていたが、まさかここまでとは。

ついでに今日現在の値段も調べてみた。

i7-4790K、最安\41800。

i5-3570K、もう売ってないのでオクで\18000前後。

FX-9590、最安\29345。

性能差ほど安くも無く。ただ8コアなので汎用機的に使うのならば良いのかも知れぬ。ひたすらエンコするにはお買い得とも言えるが、ゲームのようにピーキーなのには向いていない。

Athlon64までずっとAMDだったので、次世代のZENに期待。x86_64アーキをIntelに飲ませた頃のAMDをもう一度。

ExpressFabric PCIe Switch Chips

・ExpressFabric PCIe Switch Chips

PLXじゃなくて今はもうAvago。PEX85XX系86系87系と順調に進化を続けて、ついに97系。いや～この石すげ～ワ～。HPCの内蔵やマルチキャストDMA、ネットワークを意識したDMAディスクリプタにBDFのマスカレード等々。

ラック内でバックプレーンをコネクタで接続している分には大した問題にはならないのだが、最終的に外にケーブルを出してx8のパラレルで繋ぐとなると…。

#しかし完全に先越された。

くっ…くやしくなんかないんだからねっ！

QSFP28

取り急ぎ備忘録。

・QSFP28トランシーバー

・QSFP28マルチモードオプティカルケーブル

・DELL Z9100　これ結局broadcomのtomahawkだということが判明。ナンダカナー。ツマンーナーイ。
High-Density 25/100 Gigabit Ethernet StrataXGS® Tomahawk Ethernet Switch Series

・IEEE802.11ac 6.9Gbps

・5G

ケーブルIFまわり

・M.2

メモ。思い出すのにPCI-SIG経由で30分くらいかかった。意外とサーバ内部で使われていたりする。

・OCuLink

出る出る詐欺でさっぱり進まない規格。

現状だとGen3 x16で単方向64Gbps。もう100GEtherとかだと余裕で足りてないんだよね。とはいえシングルファイバの100Gトランシーバなんて現実的(ブルジョワGW除く)ではないので、XAUI的にx4で分割することになるのだろう。え？それなんてQSFP？ただクライアントはそれで良いのだが、スイッチは当然話が変わってくる。

ネットワーク速度の上昇に汎用バス速度の上昇が追い付いていない。真面目にもうPCIeは汎用バスというか、ローカルストレージ専用になるんじゃなかろうかと思っている。PCI-SIGの進もうとしている方向もそう見える。

結局マザーボードの外に出そうとするとケーブルを1本化する為のSerDesは避けられず、そうなると銅線でディファレンシャルペアか光化でWDMするしかない。つまりコンピュータ屋はいつまで経ってもトランシーバ屋の背中に乗っているのが現実である。

MDIO

・Management Data Input/Output

クロックも遅く至極単純なインターフェースなので接続するのは簡単なのだが、複数ポートの集合が進んでいる今風のPHYをコントロールしようとするとかなり面倒くさい。MAC層だけ持っているようなCPUに繋がっている分には、ソフトウェアで制御できるのでそうでもないが、FPGA直だと作業効率がどうしても悪くなる。PHYベンダーが自前のGUIツールを持っていたりするので問い合わせるのが吉。

MDIO部分だけPCIe経由で上位のプロセッサに渡せたりすると便利なのだが、MAC部分の実装がMDIOを包括していたりしてXilinx製のIPだとそれも難しい上に、PHYのコントロールがプロセッサでMACがFPGA内部というのもちょっと気持ち悪い。

PHYの位置とその制御、MACの位置とその制御がもっと自由に扱えたらナー。もう仮想化の流れは止められないのだから、1ポートなんて言わないでもっと細かく分割しようぜ（そしてオレに楽をさせてくれ

SGI NUMAlink7

昨日のSGI UV300の発表から辿ってSC14でのNUMAlink7へ。もう少し詳しい仕様が知りたいのだけれどあんまり落ちてないなあ。とりあえずこの辺り。

・Technical Advances in the SGI UV Architecture June, 2012
・White Paper SGI NUMAlink Industry Leading Interconnect Technology

あとこれくらいか。

・SGI UV300 – The Most Powerful In-Memory Supercomputer

NUMAlink7 provides bandwidth of up to 7.47GB/s bidirectional and All-to-All topology, ensuring the lowest latency between any processors accessing the pool of resources.

引き続き調査予定。

UV300自体は完全にHPC向けでExadataとの差別化がよくできている。アーキテクチャとしてはインタコネクトとしてIBを採用しているExadataより自前でやっているUV300を個人的には応援したい。

FPGAエクストリーム・コンピューティング

・FPGAエクストリーム・コンピューティング 第6回

毎度毎度気になり続けて第6回。行きたいと思う数少ない勉強会なのだけど、海外住みにはツラいところ。知り合いの方も登壇されるようなので、ニコ生で視聴予定。

FPGAと言えど、どちらかというとアプリケーションよりアーキテクチャ寄りに興味を覚える。プロセッサから複数のFPGAをスレーブで繋いでフォルトトレランスな多数決システムとか動的な書き換えとかやってみたいな。リファレンスボードじゃ無理なので誰かお金下さい。

動的書き換えで思い出したけど、なかなかtabulaが来ないなあ。時分割でリソース倍倍だぜというマジすかそれに期待しているのだけれど。

あ、あけましておめでとうございます。

FPGAアプリケーションエンジニア

・インテルが求める「FPGAアプリケーションエンジニア」とはこんな人

一昨日あたりから、あちこちで話題になっているのを見かける。はてブのコメントも読んだけど、まあ大体はそんなスーパーな奴はいないという感じ。ひょっとするとインテルクラスの会社（インテル製の技術ドキュメントを読むと彼らが持つエンジニアリソースの量がよく分かる）にはゴロゴロいるのかも知れないが、恐らくそういう人間は転職市場には出てこないし、日本でそのスキルを生かすのは難しいだろう。

オレが日本を離れ、台北でハードとFPGAとOSとデバイスドライバをしこしこと作っている理由もそれだからよく分かる。だって日本にそんな仕事ないも～ん。あったところで「じゃあ月80万円で明日から来てください」「嫌です」即決で却下。人月単価商売を否定するわけではないが、エンジニアリングへのリスペクトを感じないので好きではない。オレが好きなのは客と呼ばれる人達を助けることではなく（それも良いけどね）、コンピュータそのものなのだ。

というようなエンジニアリング生活を貫いていると、インテルが求めるこれくらいのスキルセットを持っている人達とけっこうな数出会うし、実際弊社にもいる。ただこれから先のビジョンに共感できるか否かという話になることも多いので、ハイヤーできるかどうかというとまた別。

まあでも気を抜くと友達を紹介するからと誘われノコノコと出て行くとネットワークビジネスの紹介で友達だと思っていたクソガキから「もっと自由に働きたくないか？」「これ以上自由でどうすんだ間抜け」「もっと給料が欲しくないか？」「お前より稼いでるわボケ」といった面倒事に巻き込まれ、荒れた酒を飲むことになるから本当台北は地獄だぜ！ハッハー！

・インテルがFPGA搭載プロセッサの投入を表明、MSの要望など反映か

こういう話もずいぶん前から出てはいるので、ますますヘテロな構成になっていくのだろう。既にZynqのようなハイブリッドなデバイスも出回り始めているし、これからもっとハードとソフトの境界があやふやになると、更にコンピューティングが面白くなるはず。

・Achronix

個人的にはここの会社にもっとがんばって欲しい。大手2社に負けるな～。

Xsigoで思い出した

この間台北の地獄のようなバーで、クライナー・パーキンスの人がいて、OracleはXsigoをいくらで買収したんだ教えろゴルァお前んとこも株主だったろガー！と泥酔して絡んだところ、やはり泥酔しておられたので、残念ながら教えてくれなかった。無念。本当台北は地獄だぜハッハー！

ARM関連

・2015年最初のハイエンドスマホCPUとなる「Snapdragon 810」は何がすごいのか？

別にすごくはないワー。2年前にARMが描いていた画そのままで、コア自体はA53/A57だし、ARMから新しいコアの発表があったわけではないのだが、インタコネクトは気になったので久しぶりにARMのサイトに行ってみた。

・CoreLink DMC-520 Dynamic Memory Controller for Enterprise

うおお！なんか新しいの出てる！DMC-400ですらスゲーなこれと思ったのにもう新しいの出てる。しかもAMBA5。いや～もう最近のARMの半導体IPの牽引っぷりは本当に大したもんだ。これでまた多くのIPインターフェースが刷新される。いやその事自体は歓迎するし、抽象化は現代のコンピューティングそのものだと言っていいくらいだと思うけれど、個人的にはちょっと重い。もう少し軽いのが欲しい。

LVDS

最近やけにLVDSにハマる。こんなに枯れていて素直なインターフェースは無いと仕様を見ると思うのだが、日頃の劣悪な行いのせいか、トランシーバが謎のリセットを繰り返したりする。というわけで論理合成中で暇なので、適当にリンク。

・Low voltage differential signaling
・LVDS Owner’s Manual
・Understanding LVDS for Digital Test Systems

FPGA内蔵のトランシーバの性能が上がっているので、現在の速度は５Gbps超で使用されるケースも多い。

今日のおっと思ったニュース

Dell to Ship Open Switches with Midokura’s OpenStack SDN

SNSで流れてきたのをキャッチ。なるほど、以前からOSSにしたいとは聞いていたけれど、これが水面下で動いていたから踏み切れたんだな。他にまだありそうだけど、これでSDN界隈がまた面白くなった。

SDN Advent Calendar 2014

SDN Advent Calendar 2014

折角なので参戦。お題はSDN。つまり現在自分達がしている仕事のことを書けば、そのままSDN話になるのだけれど、それが大人の事情であんまり突っ込んだことを書くと怒られるだろうなあというのが容易に想像できてしまい、特にネットワーク界隈というかインフラの世界はどうも秘密主義の空気が蔓延していて、それだけカネになるってことなのかしら？などとゲスパー中。

何言ってんだお前と言われる前に自己紹介。Bonetと呼ばれるPCIeベースのインタコネクトを開発する会社でCTOをやってます。ハード屋とか思われてますが、大昔OSSをメインでやってたSI屋の中でJavaとか書いてました。それからずっとOSSとLinux kernelとデバドラでメシを食ってきて、ガチのハードやFPGAはここ10年くらいの話。Distributedなシステムアーキ全般に興味。

SDNは1年前にのんびりと次世代インタコネクトの設計をしていたところ、突然現れたにっちもさっちもいかない某プロジェクトに気が付いたら巻き込まれていたという極めて不幸な出会い。今でもOFの仕様書の解釈をめぐりオレの貴重な休日が費えたりしているので好感度はかなり低い。これは何か似ているなあと思ったら受験勉強のソレに酷似している。あ～思い出したら腹が立ってきたああ！細かく書きたいけど書けないいい！（この辺り実に大人である

SDN という言葉のいま

それでは話の枕を安田さんに頂いて、「SDN」という言葉が本当に世に浸透したなと思うと同時にもうNが取れていて「SDN」ではなく「SD*」のSoftware Definedが氾濫している。よく聞くのがInfrastructureとDataCenterで、インフラはまあ分からないでもないけどデータセンタはセンス無いナ～と思いつつも、これからは「SDI/O」だぜと言い続けていた自分も同じ穴のムジナであろう。なんでもかんでもSoftware Definedにすれば良いというものでもないが、「SDN」はとにかく仮想化したがりなエンタープライズ需要との相性が極めて良い。

止まらない。管理も容易。必要に応じて性能がスケールする。大体はこんなところなのだが、そんなのアプリレベルで実現すればベンダーも儲かっていいじゃんと常々思っていたところ、「SDN」のようなネットワークレベルで更にコンピューティングのコモディティ化を促すような概念（技術じゃない）が出て来て、西海岸の人達はどうしてこう自分達の首を絞めるのが好きなのだろうか、ちょっとはそれに巻き込まれる我々の身になれと感謝と恨みの念でいっぱいである。

そして案の定、OVSに代表されるソフトウェアスイッチが百花繚乱。さらにコストを押し下げ、辛うじてまだミドルエンドのエンタープライズなハードスイッチ需要が残っているが（ハイエンドはそもそも仮想化に向いていない）、Control PlaneとDatapathのインターフェースがはっきりと仕様化されれば、いずれはそれも駆逐されていくだろう（OFとその他の市場争いもあるけどここでは無視）

ここまでインフラが整うとIoTという言葉が現実味を帯びてくる。低速・低価格のベストエフォートな回線ではPacketIN上等、高速・高価格の固定回線ではPackeINを可能な限りさける（というより多くの場合overlayだろう）というような運用がデフォルトになっていく。分かりやすい。従って「SDN」は、一番下のカオスなどんなパケットが飛んでいるか分からないネットワークを収拾するのに非常に向いていて、上位のある程度秩序だったネットワークでは信頼性等の別の問題が発生し、だからこそそこの仕様を切り取り、ハード化するには向いているとも言える。

と、ここまでが一般的なイメージで語られる「SDN」（入ってきたパケットを加工し特定のポートから出すという意味で）。最近OFの仕様書をにらめっこしながら、頭を痛めているのがキュー・QoSに代表される回線分割技術だ。

数年前XsigoがOracleに買収されたときに、どこかのメディアがXsigoをSDNを主体とする企業として紹介していて思わず苦笑したものだが、今ならはっきり分かる。XsigoはSDN企業だった。10GbEのNICを仮想化し、インターコネクトをIBにして、各CPUからは仮想NICからIBのインターコネクトを仲介し10GｂEにアクセスというのが主旨だったように記憶している。当時はI/O仮想化が目立つ時期だったので、Xsigo自身もそのように売り出していた。だが今思えば、GUIから動的にリモートのNICを作り出し、回線速度を絞れるのはSDN+仮想化そのものだった。ただそれがラック内で完結していた為、気が付かなかっただけなのだ。

逆に言えば、それくらい隣のラックは遠い。インタコネクトを専門とする我々からすると此岸と彼岸くらい離れている。フロア内を這い回るのは今や徹底的にコモディティ化されたEthernetの独壇場で、FCすらEthernet上に統合されて随分経つ（まだ過去の資産では存在するのだろうけど）。もはやカテゴ5eのケーブルを適当に繋いでもFabricという言葉で誤魔化され（まあこれもSDNの一種と言えよう）、何とかなってしまうのが現実。そんな中にえーとすいませんこれ専用のケーブル（しかも太い）なんですけど、ちょっと使ってくれませんか？とお願いしたところで、口も聞いてくれないのがオチだ。

その上Intelが世の外付けインタコネクト屋をガチで殺しに来ていて、SC14で

Intel、第3世代のXeon PhiとXeon Phi向けインタコネクト技術を発表

「Intel omi-path architecture」なるものが発表されている。以前からプロセッサに統合された100Gbpsベースのインタコネクトを開発している話は聞いていたが、ここまで具体的な数字が出てきたのは驚きだ。数年前にIntelがQlogicのIB部門を買収し、自分達で3GIOとして仕様を作った後に見捨てたIBに対し悔悟の念でもあるのかと思いきやこの仕打ち。さすがIntel！トランスメタへの露骨な嫌がらせを思い出して涙が止まらない。

ただ冷静に考えるに、恐らく外付けのインタコネクトはもう変化せざるを得ない。既存のアーキテクチャでは、プロセッサが抱え込んだインタコネクトには太刀打ちできない。京で採用されている富士通製SPARCのTOFUもそうだし、AMDもSeaMicroを買収し同じような方向に舵を切っている。この辺りは安田さんのこの記事が詳しい。

64ビットARMクラスタへの道のり―Gary Lauterbach氏へのインタビュー～AMDの64ビットARMチップ“Seattle”のカギを握るFabricテクノロジはどこから来たか（前編）

インタコネクトは純粋にインタコネクトとして使用される場合、帯域よりもLatencyが圧倒的に重要で、とにかくデータに近いことが要求される。これから先のコンピューティングにおいてインタコネクタデバイスがPCIeの向こう側にいるのは、残念ながら致命的に遠い上に、仮想化と外部デバイスからのDMA転送の相性が悪すぎて、苦肉の策のIOMMU使用時の性能劣化は顕著に過ぎる。割り込みの遅延も深刻で、それを回避する為に1コア丸ごとポーリングでデータの到着待ちをMPIでカバーしているのがHPCアプリの実態。当然本来そんなものはハード側で処理すべきだ。

ただこれらの問題はプロセッサ直付けのインタコネクトも抱えているので、外付けインタコネクトな人達はその辺りに注力していくことになるのかなと感じている。特に割り込み処理は現在出回り始めている半ASIC・半FPGAなデバイスの格好の課題で、かつSoftware Definedで上位レイヤーから統合的に管理できると面白くなるなあと、末端のインタコネクト屋としては思う。

更にRDMA（iWarpぅ…）も含めてもっと書きたかったのだが、長くなったので今日はここまで。以上、SDNを含む四方山話。