【その他】リモートデスクトップでrdpファイルにselectedmonitorsの記述をしてもうまく動かないときの確認点 
2024, March 28, Thursday, 00:13 - PC, Other
投稿者 @xmms



  Windowsのリモートデスクトップですが、実はマルチモニター環境で特定の画面だけにまたがって全画面表示する、という機能があります。この機能を使ってとあるVMで作業するときに「1枚の全画面だと微妙に使いにくいけどマルチモニタすべての画面をリモデに使いたくない」という要件を満たすべく2枚の画面だけを使うようにしていました。

https://www.hanselman.com/blog/how-to-remote-desktop-fullscreen-rdp-with-just-some-of-your-multiple-monitors
https://qiita.com/yusuke-sasaki/items/5f70dc266caf13021838

　先に結論を書くと、 RDPで複数画面が使えない!というときは、使いたいディスプレイ同士が0pxで隣接しているかを確認する必要があります。以下、検証のメモです。


　実際のモニターのセットアップはこうなっています。グラボの出力順を考慮していないのでぐちゃぐちゃになっていますが、この中から5,6を使ってRDPを全画面表示する、ということをしていました。




 今までこれは動いていたのですが、モニターのつながっているグラボの出力端子を入れ替えたタイミングで画面をまたがっての表示が動かなくなってしまいました。 mstsc /lで調べてみると、端子が入れ替わったことによってモニターのIDが変わっていたので、IDを確認してrdpファイルに書かれている順番を入れ替えれば動くだろう、と思いました。しかし、若干の移動はあったもののIDは大きく変わっておらず、何をやってもモニタをまたがって全画面表示ができずプライマリモニタだけ全画面で表示される挙動を示しました。

　よくわからないので一度マシンを再起動し、もう一度mstsc /lをすると今度は何故かモニターIDが大きく変わっていた(1,3,10,11,12,13から0,1,2,3,4,5になっていた)のですが、それを直しても動かず、色々検証すると下記設定の赤字0,2の2画面表示と5,3の2画面表示は問題なく動き、なぜか5を含むと動かなくなるということがわかりました。




　検証に使った最低限の要素だけ含めたrdpファイルは以下になります。

## NG ##
full address:s:VM1
use multimon:i:1
selectedmonitors:s:4,5
dynamic resolution:i:0


## OK ##
full address:s:VM1
use multimon:i:1
selectedmonitors:s:0,2
dynamic resolution:i:0


　プライマリモニタがRX7900XTXにつながっていることもあり、最初はRadeon仕草かと思いましたが、 mstsc /lの値をよく見るとmstsc側ID(画像赤文字)の5の起点座標がおかしい事に気が付きました。この場合、0,0から3839,2159が4の値なので5が3840から始まらないといけないのですが、なぜか3853となっており、赤字4と5の間に13ピクセルの隙間があるいうことがわかりました。

　カッコ内部の値はそれぞれプライマリモニタ(この場合は赤字の4)の左上を0,0として右下に向けて座標がプラスになり、プライマリモニタより左にモニタがあればxはマイナスに、プライマリモニタより上にモニタあればyがマイナスになります。

　Windowsの仕様として隣り合うモニタ同士はどこかでくっついていないといけないのですが、赤字5は赤字3とくっついているという扱いになり、4と5は13ピクセル離れている、という認識になっているようです。出力端子を入れ替えたのがちょうど赤字の5にあたるものだったのですが、Windowsで画面の位置を移動したときにそれがズレたようです。わかるかそんなモノ…。

　離れてるのであればマウスの移動もできないのではと思いましたが、ある程度の加速度があると多少の隙間を乗り越えて隣のモニタに行けるようです。逆に、隙間があるととてもゆっくりマウスを動かしてモニタの境界線をまたごうとするとブロックされます。密着しているとマウスカーソルの加速度が1px/sでも境界をまたげるようです。たまに感じた違和感はこれだったのか…。




　ディスプレイのスナッピングとの格闘の末、最終的に一回り小さい赤字の1以外は0pxで整列できたのですが、どうしても最後の1つが完全密着になりませんでした。1の値は1279,ｰ1440,3840,ｰ1になるべきなのですが、Windowsのディスプレイ設定は2辺と隣り合うことを想定していないのか、赤字の3の左辺、もしくは4の上辺のどちらかにしかスナップせず、逆にどちらかにスナップすると絶対にもう一方は合わないという動きをしていました。

　ただ、赤字の0,2,4,5の横一列は整列されたので、当初赤字4,5の2画面でリモデが使えないという問題は解決しました。現状、赤字の1,3を使って画面をまたいでリモデをする、ということができませんが、このパターンはないと思うので諦めました…。座標を使ってディスプレイの場所を指定できる方法があればいいんですが…。



　変な環境でディスプレイを出力していてRDPで複数画面が使えない!というときは、使いたいディスプレイ同士が0pxで隣接しているかを確認する必要がある、という、ほんとに使い所のないナレッジを得たのでここに供養します。


[ コメントを書く ] ( 63 回表示 )   |  このエントリーのURL  |  $star_image$star_image$star_image$star_image$star_image ( 2.8 / 50 )  |  
【HW】複数枚のGPUを搭載したWindowsのGPUの扱いについて 
2024, January 12, Friday, 03:46 - PC, HardWare
投稿者 @xmms
複数GPUを搭載している環境だと、WindowsのバージョンによってセカンダリGPUの扱いが違うというのがあるのでそのメモです。前回の内容に入れようと思った内容だったのですが長くなりすぎたので分けました。

昔は表示しているディスプレイごとに使うGPUが違った


　古のXPからW10の何処かのバージョンまでは、グラボが複数あってそれぞれ画面を出力している場合、その画面を表示しているGPUがその内容を処理していました。
　そのため、ゲーム用に使うGUPは画面を1枚だけつなぎ、それ以外の雑多な内容を表示するためのをGPUを別に搭載することによって一種の負荷分散が出来ました。1080を買った直後くらいまでは「ゲーム用GPUは画面を1枚だけ出すのが一番パフォーマンスが出る」という動きをしていた記憶があります。

すべての処理がプライマリGPU処理に


　それがWindows10のどこかのバージョン(20H2くらい?)からすべての内容はプライマリGPUで処理し、その結果を各ボードのRAMにコピーする、という挙動になっていました。その結果、 利点としては HEVCの動画やウィンドウモードで起動したゲームなどを、低性能なセカンダリGPUにつながっているディスプレイ領域にもっていってもそれなりに動く、という挙動になりました。




　上記はセカンダリGPUとしてつながっているQuadro M2000から出力しているディスプレイにWindowモードで起動したARKを持っていった際のスクショですが、1080でも厳しい内容であっても処理している実態は7900XTXなので余裕で100FPS出ています。

　しかし、欠点としてはどうやってもプライマリGPUの負荷だけが上がるようになり、違うGPUにつながっているディスプレイにブラウザなどを置くと、プライマリGPUで描写→セカンダリGPUのVRAMにコピーという無駄なステップが増えてしまったり、セカンダリGPUのVRAMやビデオデコーダが有効活用できないという問題がありました。

無理やりプログラムが使うGPUを指定する


　プロセスが利用するGPUは、プロセスが立ち上がるときにプライマリになっているディスプレイ(「このディスプレイをメインディスプレイにする」のディスプレイ)がつながっているGPUとなります。
　一時期はブラウザを起動する前にプライマリディスプレイをセカンダリGPU側のディスプレイに変更し、ブラウザの起動が終わったらプライマリディスプレイをもとに戻す、ということを行うことによって強制的にブラウザの処理をセカンダリGPUにさせていた時期もありました。
　ただ、これをするとFirefoxがWebGLをレンダリングできなくなるというような問題があったので微妙なところでした。

Win10から処理するGPUを指定できるようになったが…


　Windows10の21H2くらいからプロセスを処理させるGPUを指定できたのですが、試したところ省電力、高パフォーマンスというくくりは、UDHグラフィックスなどのiGPUを省電力GPU、それ以外のディスクリートGPUは高パフォーマンスGPUというくくりでした。
　なので、両方ともディスクリートであるM2000と1080という組み合わせの場合、どちらかを省エネグラボに指定する、ということは出来ませんでした。
https://forest.watch.impress.co.jp/docs/news/1270962.html

　M2000を省電力、1080を高パフォーマンスと指定できる方法がないかと探したのですが、結局iGPU以外は省電力GPUとして指定することは出来ませんでした。

Win11でいつの間にかプロセスのGPU割当機能が追加された


　7900XTXに換装後も4k複数枚でブラウザを起動したままにしていると相変わらずVRAMを10GBとか消費することがある(ブラウザを閉じてもDWMが4GBくらい抱えたままになる)のは解消しませんでした。メモリに余裕があるとはいえ流石にどうにかしたいです。

　WindowsUpdateを当てたらマシにならないかとWindowsUpdateを当てることにしたのですが、上記のグラフィックスのInsider previewを試すためにDevビルドにしたままなのを忘れていて、久しぶりにUpdateを当てたらWin11のInsider previewが降ってくるという事故を起こしてしまいました。
　意図せずWin11(のInsider preview)になってしまったのですが、ロールバックする前に今の環境をWin11にした場合の挙動を確認することにしました。

　仕事では13世代のi5を使う関係でW11を使っていますが、W10に比べてすべての動作が緩慢なのでW11をメイン機に入れたくないと思っていましたが、使ってみると「あれ…なんか逆に調子いい?」という感じだったので、そのまま利用を続行しました。CPUはRyzen 5 5600XなのでP/Eコアというものはなく、OSはどちらを使っても問題ないはずなのですが…。

　そして、いろいろな設定を巡っているといつの間にかプログラムを処理するGPUを指定できるようになっていました。




　W11も初期のバージョンはこの「特定のGPU」という選択肢がなかったように思いますが、いつの間にか増えていました。確認したバージョンは Insider Preview Build 23612 (Dev Channel)となりますが、ビルド的に多分22H2くらいにも入っている気がします。

　その結果、ブラウザでなにか調べたり動画を見たりするときにはセカンダリGPUのVRAMやビデオデコーダがが使われるようになり、いい感じに動くようになりました。




　もっと前にこれができるようになっていてほしかったですが、ようやく欲しかった機能が実装されました。

まとめ


　プライマリGPUがミドルクラス〜ローエンドのグラボを使っていて、補助GPUを使って少しでもプライマリ側の負荷を下げたい、というときにはこのオプションは有効だと思います。

　現行のミドルクラスならベース性能がかなり上がっているのでその必要もない気はしますが、VRAMが8GBクラスのものだとゲーム用にメモリを空けるためにブラウザ処理用の補助GPUが欲しくなる気もします。
　ちなみに4kだとゲームを起動すると8GB位のメモリはあっという間に使うので、4kでゲームをしたいなら12GB、できれば16GB以上は必要だと感じました。

　動画のHWエンコードソフトから使うGPUを選べないような場合も、強制的に使うGPUを指定することによって負荷分散ができるようになります。1080とM2000を組み合わせたときにはOBSやD3DGearのHEVC録画はGPUを分けたほうがゲームのFPSは安定していました。

　また、プライマリGPUの性能が高いのであれば、 NVS810 のような1スロットで8枚DPをはやせるGPUでもプライマリGPUの性能によって快適に使えるので、ある種のハブとして使うといった柔軟性がかなり高くなったと思います。
　

　こういったカーネル周りに手が入って良くなっている感じはするので、事故で上げてしまったW11はW10に戻さずに使うことにします。

以上


[ コメントを書く ] ( 79 回表示 )   |  このエントリーのURL  |  $star_image$star_image$star_image$star_image$star_image ( 3 / 91 )  |  
【HW】グラボの消費電力を下げるためにFSR/RSRを使う 
2024, January 12, Friday, 02:16 - PC, HardWare
投稿者 @xmms


　普段使っているモニタを4k*4枚に変更したのですが、ふとゲームをしようと思ったら今まで使っていたGTX1080では処理能力が足りなくなったためグラボを変えようと思っていたところに、じゃんぱらでRadeon RX7900XTXがなぜか特価で出ていたため久々のRadeonにしました。その時に色々検証したのでその時のメモです。

ことの発端


　仕事でモニタを使うときに、置く場所の関係であまり多くのモニタを置くことができなかったので、モニタの中に極限まで情報をぶち込みたいという欲求から27インチの4Kモニタをスケーリング無しで使っていました。目を潰しながら4kを使っているうちに慣れてきたので、家で使っているモニタも4kにしようとすべて置き換えました。
　1枚だけ変えると色味が合わないとかベゼル位置が合わないというような微妙なストレスが嫌なので 4kを複数枚買いましたが、使ってて思うのは個人的には27インチWQHDくらいの解像度がベストだと思います。
　27インチ4kモニタは11インチのFHDモバイルモニタを4枚並べたときとDPI的に同じになるのでスケーリングなしにするとまあまあ厳しいですが、現代のITエンジニアは眼球に可能な限り多くの情報を詰め込む必要があります。

　モニタを変えてからしばらくは忙しくゲームをする暇と気力がなくてオフィス用途でしか使っていませんでしたが、ふとARK: Survival Evolvedを起動してみたところ、すべてEpicの状態で4kネイティブで起動すると20FPSくらいしか出ないという状態でした。
　ゲームしたいときに出来ないというのは問題なのと、4k複数枚の環境だと普通に使っていてもDWMプロセスやFirefoxなどのブラウザがVRAMを消費していって8Gのうちの5GBを消費しているようなことがあったので、いい加減グラボを変えたいという思いが強かったので新しいものを買うことにしました。

グラボ選定


　最初は4080を買おうと思っていたのですが、じゃんぱらで7900XTXが特売されていたのでVRAMが24GBと多いという利点からこれも候補に上がりました。色々比較すると、

・純粋な3D処理能力は4080よりも高い場面も結構ある
・すべてのタイトルでDLSSなどの機械学習が使える訳では無い
・7900XTXの特価は12万だったが4080はどうしても18万くらいになる
・RTX5000シリーズが先送りになったのでRTX4000シリーズの価格が下る要素がなくなってしまった
・VRAMが多いので雑に使っても心の余裕がある


　となり、過去散々ATiのグラボで色々踏んだ事があってもまあいいかなと思えたのでポチりました。

　VRAMがそんなに必要になるか、と思うかもしれないですが、3ヶ月位(下手すると1年)再起動せずにブラウザのタブやウィンドウを大量に開いたまま使っているとVRAMの使用量が肥大化していき、VRAMが足りなくなるとブラウザやOSの挙動がおかしくなり、すべてのブラウザを閉じるという必要が出てきます。
　ブラウザをすべて閉じても今度はWindowsのDWMがVRAMを握ったままになり、その状態でゲームをするとスワップのような挙動になる事があり、解消には結局再起動が必要になってストレスだったりします。

　使い方が悪いのでは??というのはそうなんですが、原状どうにもならないのでこの使い方だとスペックによるパワーで押し切るしかないです。また、4kという解像度が1枚でFHDディスプレイ4枚分の表示面積があるので、それを複数枚となると相応のスペックが必要になります。
　27インチで4kの解像度でゲームをする必要があるのかと言われると、別に画質を求めているわけではないのですが、フルスクリーンの解像度変更によって開いているウィンドウがめちゃくちゃになるのが嫌なので、どうしてもネイティブの解像度で出したくなります。

　ただ、こういった変な要求がなければ現在では性能や値段、発熱や消費電力の扱いやすさから4070あたりが妥当だと思います。また、自分は今のところ常用デスクトップ機で機械学習をさせるつもりはないのでRadeonも候補になりましたが、普段機ででお絵かきAIも動かしたいというような要望があると必然的にGeforceが候補になるかと思います。


わかっていたけど高い消費電力


　グラボを換装した感想ですが、4kでもARKなど今までやってきたゲームがコマ落ちせずかなり快適に動くので1080との性能差を実感しました。ただ、それに比例して消費電力が増えたので、 AMD Software: Adrenalin EditionというAMD謹製のGPUのモニタリング、チューニングをするツールから消費電力を監視し、これを下げる方向にチューニングする方法を模索することにしました。




フレームレート制限で消費電力を下げる


　ARKを遊んでいるとGPUだけで350Wくらい行ってしまうので、どうにかこれを下げられないかとアレコレしていると、当然ながら負荷が下がればそれに伴って消費電力も下がることがわかりました。60Hzのディスプレイなので、それ以上のフレームレートは無駄になってしまうため、まずはフレームレートの固定を行いました。




　HL2やL4D2などでゲームからV-Syncを有効にすると明らかな入力ラグが出るので今まではティアリング上等で200FPSなどのフレームレートを出していましたが、FreeSync対応モニタなのが有効なのかドライバが賢くなったのかわかりませんが、Adrenalineからフレームレートの制限をかけると気になるラグは出ませんでした。
　80-90FPS出ていて350W消費していたのが60固定にすることによって300Wくらいに落ちたので、もう少し下げられないか試してみました

RSRなどのアップスケーリングを試す


　Adrenalineの設定にRadeon Super Resolution(RSR)という項目があったのでこれについて調べてみると、ゲームの解像度をネイティブ以下に設定したフルスクリーンゲームを起動した際にドライバ側でネイティブまでアップスケーリングして出力する、という機能だとわかり、試しにゲームから解像度をWQHDにしてRSRを有効にしてみるとかなり効くことがわかりました。
　具体的にはRSRを使うことによりフレームレート制限と合わさりGPU負荷が80%まで下がり、消費電力が一気に180W程度にまで落ちました。ただ、ゲーム自体はネイティ解像度以下で出力されるため、開いているウィンドウがぶっ飛ぶ問題は起きてしまいました。

　よく見てみるとAdrenalineの説明にFSRをドライバレベルで実行するのがRSRである、という文言があったのでこのFSRについても調べてみましたが、FSRとは FidelityFX Super Resolutionの略であり、こちらは出力するテクスチャの解像度を内部的に落としたあと、グラボでアンチエイリアシングなどの処理をしたあとにアップスケーリングをかけるという技術になるようです。
　ただ、FSRについてはゲーム側の対応が必要になるようなので、そもそもARKなどは対応していないのでは?と思いましたが、ゲームのオプションにあるResolution scaleというのがアップスケーリング前に描写するテクスチャの画像になるようです。しらなかった…




　FSRについては思いっきり解像度を下げると流石にテクスチャの不鮮明さが目についてしますが、27インチ4kであれば7-8割位のスケーリングならネイティブと遜色ないレベルになりました。
　60FPSの制限の中では画質と消費電力のトレードオフになりますが、違和感のないところでWQHDのRSRと同じ180Wかそれよりも若干高い200W程度で落ち着きました。もとの350Wに比べたらだいぶマシになりました。

ついでにDLSSなどについても調べてみる


　AMDのグラボなのでNVIDIAの技術であるDLSSは使えないのですが、こちらについても調べてみたところ、やっていることとしてはFSRと同じ低解像度テクスチャのアップスケーリングだとわかりました。
　違いとしては、FSRはスケーリング処理をシェーダーとして扱うため特殊なコアが必要ないという特徴がありますが、DLSSはその処理をTensorコアなどの専用プロセッサで行うので対応したグラボが必要になる、ということみたいです。
　事実、FSRは1080でも利用できたようなので、実はこれで誤魔化せばグラボを買わなくても耐えられたのでは…という思いはありますが、FSRを行うにもグラボ側の余裕がないと効果がないようなので多分意味はあったと信じます。まあ、VRAMが足りない問題は出ていたので…

　DLSSの進化系であるDLSS-FG(Frame Generation)は、実際のレンダリングフレームの間にTensorで(描写済みのテクスチャからいわば画像として)作成したフレームを挟むことによりフレームレートを上げる処理になるようです。同じような技術がFSR3でも実装されるようです。
　ただ、補完フレームを挟む必要があるので入力から出力までのバッファが必要になり、入力のレイテンシ低減にはならず、むしろ増える方向になるようです。FSR/DLSSは実際の描写が軽くなるためこれを有効にすることによって入力レイテンシが下がるらしいです。



　フレームレートと入力遅延が一致しないというのはなかなか難しいですが、GPUの性能が足りずそもそもコマ落ちするレベルでレイテンシが上がっているようなときにはDLSS-FGのレイテンシのほうがマシになる可能性はあります。

まとめ


　昔は「ドライバのフィルタ処理で正しくテクスチャを描写してない!手抜きだ!チートだ!」 みたいなことを言っていた時期がありましたが、今となっては「クソ真面目に描写するのは馬鹿らしいからAI使って補完しようぜ!」みたいなことを言い始めるあたり時代を感じます。まあ前者についてはただの言いがかりですが。

　フレームレートを増やす技術というのは言い換えれば同じフレームレートなら負荷が下がる技術ということになるので、極端な高フレームレートディスプレイを使っていないのであれば消費電力を下げる恩恵があるというのを実感しました。
それなら下位のモデルでもいいのではないかと思うかもしれませんが、これらの技術が (RSRは原理的に使えそうではありますが) すべての場面で使えるわけではないというのと、ベーストルクがあるからこそできる余裕というのもあるので、グラボを買うなら個人的にはある程度の上位モデルをおすすめしたいです。

　ただ、11月ごろに7900XTXを買ったのですが、2月に4080Superが15万くらいで出るらしいというのを見て「それならそっちにしたわ…」みたいな気持ちはあります…。まあ、こんなことでもないとRadeonを買うこともなかったと思いますし、使ってみたら改めて知ることも多く、AI以外の用途なら悪くないというのがわかったので良しとします。
　7900XTXも出始めの頃のドライバの出来は相変わらず散々だったようなので、他人におすすめするときは「Geforce買っておけ」と言いますが…。

　FSPカウンタなどで高いフレームレートを見ると気持ちがいいですが、逆に消費電力を減らす方に振ってみるのも面白いと思いました。

以上




余談:過去のATiで踏んだもの


　3870を2枚でCrossFireしていたときが一番ひどかったです。CFを使うとどのドライバでも何かしらおかしかったので、その出来の悪いドライバから一番マシなのはどれかを探すのが大変でした。ジャンク漁りかな?
　どれも出来が悪いので、毎月出るCatalystドライバに今抱えている問題が直らないかという僅かな願いをかけて更新するのですが、ひどいものだと入れたら最後、青くなって戻ってこれなくなるということが多々ありました。月刊Catalyst!今月号の付属はきれいな青画面つき!!!みたいな感じでした。
　まあ、そのあとGTX295を使いましたが 結局nVidiaでもデュアルチップはうまく動かない事が多く、その後使ったHD4890は安定していました。


余談:買ったモニタ


　モニタについてはそこまでこだわりがないのですが、1枚だけ変えると色味が合わないとかベゼル位置が合わないというような微妙なストレスが嫌なので、使っていた4枚をすべて交換する前提で安いものを探していました。するとAliで162ドルのものが見つかりました。 (今は絶版になってますが)




　モバイルモニタなどの中国製モニタをいくつか試した経験から、今の中国製のモニタのパネルはそれなりに品質が高いという経験則と、ベゼルに変な文字が入っていないのと、何故かこれだけ大きいにも関わらず送料が無料だったので 、試しに1枚買って1ヶ月検証したのですが、そこそこ良かったので計4枚買いました

　まあ買った時期によって(もともとできるとは書いていなかった)入力のPiPができるリビジョンとできないリビジョンが混ざっていたとか、 旧リビジョンのモニタについてきたACが公称消費電力が45Wに対して12V/3.33A=40Wという微妙に出力の足りないACで「大丈夫かこれ」とか思っていたら案の定1ヶ月でACが壊れたとか、解像度をWQHDにすると144Hz駆動にする裏オプションが存在するとか、大陸しぐさ満載でしたが、鍛えられてくるとむしろそれが楽しくなってきます。 色んな意味でシビレますね。

　ちなみにACについては汎用的な2.2/5.5mm径のACなので在庫が家にくさるほどあり、12V/5Aのものに交換して無事に動きました。それを口実に紛争を開始して部分的な返金を受けられたので良しとします。向こうも知ってか後期リビジョンではACが最初から12V/5Aのものになっていました。色については初期は黄色みが強いですがOSDで調整すればいい感じの発色になりました。





[ コメントを書く ] ( 109 回表示 )   |  このエントリーのURL  |  $star_image$star_image$star_image$star_image$star_image ( 3 / 83 )  |  
【HW】 おうちでinfinibandを使う 2022 / SCSTのビルド 
2022, November 13, Sunday, 09:21 - PC, HardWare
投稿者 @xmms



　普段便利に使っているESXiの環境ですが、ESXi7x以降になるとvmkAPIのバージョンが上がり、ネイティブドライバが配布されていないとドライバの認識ができないため、古いマイナーなハードウェアがだいぶ認識できなくなります。こちらの環境では未だにストレージがInfinibandとSRPに依存しているので6.7から進めずにいます。




　そんな中、普段動いているストレージのIB接続がESXiからみてesxtopでFCMD/sが跳ね上がるときがあり、なんかストレージが調子が悪い、ということが稀に起きるようになってきました。問題が起きるとストレージ自体の再起動をしてもだめな時があり、VMホストを再起動しても解消しないことがありました。いろいろな検証の結果、どうやらVMホストに刺さっているHCAは問題ないようで、ストレージホストに刺さっているHCAがなにか悪そうな感じでした。
　このIB HCAも相当長く使っているので、そろそろ交換してみようと思い、手元にCX2の在庫があるもののebayを見てみたら、FDRなHCAが9ドルで売っていたので買ってしまいました。もうIBは買わないと思っていたのですが…。

ハードウェアについて





　対象のHCAはEC33という型番で売られており、Connect-IBのDPモデルのようです。ちなみにCX2とブラケットの互換があったため、DDRなCX2からブラケットをはいで使いまわしました。




　燦然と輝くFRU PN / NAの文字。謎が多いです。




　Connect-X4などはEtherとしても動かせるためまだ需要があるのですが、Connect-IBは完全にIB専用のため、かなり不人気です。9ドルでもいらないというのが全てですが、こちらの環境だと逆にスイッチがEtherを使えないので都合が良いです。

IBについて


　IBは基本は広大なL2で使うという単純な作りがゆえ、QDRな32ポート40Gスイッチ(Voltaire Grid Director)であってもポートをたくさん使っても消費電力が70-100W程度と非常に低く、ストレージインターコネクトとして使うにはとても優秀です。
　ただ、IBにはL3ルーティングやVLANなどがない(パーティションを分けるためのP keyがあるといえばあるものの…)うえ、SubnetManagerなど独特な作法があり使いづらいし、ネットワーク的にみんなほしいのは結局Etherだよね、となり、EtherでRoCEなどを使うのが今どきのRDMAですが、自宅環境で使おうとすると新しくスイッチとNICを買わないといけない、スイッチを買っても40GだとIBからそこまで変わらない、40Gスイッチで多ポートのものになると消費電力がかなり上がる、などの理由があり、用途次第では未だにIBにはメリットがあります。

　FCがそこそこまともに動けばよいのですが、8G-FCでLinuxターゲットを作ったときにはあまりパフォーマンスが出なかったので、結局全て売ってしまいました。その時はLIO+targetcliで検証しましたが、32G-FCとCSCTならもしかしたら改善しているのかもしれません。しかし、FC HBAをイニシエーターではなくターゲットとして動かすには多少の手間があり、かつまだそこまで32G-FCが出回っていないので現在どの程度出るのかは不明です。ただ、RDMAの高速性、低負荷性を見てしまうと微妙な気がします。

SCSTでSRPターゲットが動くのか2022


　現在動いているストレージはDebian9までは上げましたが、それからは塩漬けになっています。現在のDebian11はカーネルが5.10となり、カーネルモジュールとしてib_srptを読み込むSCSTはカーネルとの兼ね合いがありそうで無事に使えるのか、Connect-IBはドライバとしてmlx5をつかむのでこれもいけるのか、という疑問がありました。LinuxはINBOXでib_sprtドライバを持っているのですが、LIO+targetcliだとずっと使っているとSRPがなにかのタイミングで刺さるということが多々あり、パフォーマンスもSCSTのほうがかなり良かったので過去の経験からSCSTを使っています。LIOももしかしたら良くなっているのかもしれませんが、過去から現在の実績があるのでSCSTにこだわります。

　様々な検証をした結果、結論から言いますと無事に動いています。以下にSCSTのビルド方法などを書きます。

SCSTのビルド



　昔は小細工が色々必要でしたが、今は素直にビルドできるようになっています。まずはgit,make,gcc,linux-headersを入れます。

root@debian:~# apt install git make gcc linux-headers-amd64


　次に、gitからソースをダウンロードし、makeします。make allでもいいのですが、FCターゲットなど通常使わないものも含まれているため、一つ一つ指定して作ったほうが早く終わります。今回はSCSTに必要なパッケージ、srpt、iscsiモジュールをビルドします。ここで注意が必要なのは、順番的にscst_installを先に持ってこないと他のビルドがコケます

root@debian:~# git clone https://github.com/SCST-project/scst.git
root@debian:~# cd scst/
root@debian:~/scst# make scst_install scstadm_install iscsi_install srpt_install


　ビルドが終わったら、depmodで新しく追加されたモジュールを反映します。

root@debian:~/scst# depmod -a


　これで、SCSTの前準備が完了しました。正しくモジュールが入ったか、modinfoで確認します。import_nsがSCSTになっていれば問題なくビルドできています。

root@debian:~# modinfo ib_srpt
filename:       /lib/modules/5.10.0-10-amd64/extra/ib_srpt.ko
import_ns:      SCST
license:        Dual BSD/GPL
description:    SCSI RDMA Protocol target driver v3.7.0-pre#in-tree (11 January 2022)
author:         Vu Pham and Bart Van Assche
depends:        scst,ib_core,rdma_cm,ib_cm
retpoline:      Y
name:           ib_srpt
vermagic:       5.10.0-10-amd64 SMP mod_unload modversions
sig_id:         PKCS#7
signer:         SCST Kernel Modules


設定ファイルの作成


　昔はscstadminで色々やっていましたが、設定ファイルをある程度作って読み込ませたほうが楽なので以下にサンプルを置きます。SCSTのIBのGIDは/sys/class/infiniband/mlx5_0/ports/1/gids/0などにあるので、こちらをcatなどで開きます。

root@debian:~# cat /sys/class/infiniband/*/ports/*/gids/0
fe80:0000:0000:0000:5849:560e:5c50:0401
fe80:0000:0000:0000:5849:560e:5c50:0409


　以下のサンプルはFCでいうところのLUNマスキングをしていない、すべての接続を受け入れてマウントを許可する設定になっています。場合によってはマスキングをしないと意図しないマウントが発生してファイルシステムが壊れるので注意してください。今回はVMFSとESXiからの利用のみを想定しています。TARGET_DRIVER copy_managerは無くてもscstadminが勝手に増やすものなので正直なんだかよくわかりませんが、書いておかないとターゲットの更新をするときなどに--forceをつけて読み直したときに色々終わるので必要なものになります。

cat /etc/scst.conf
HANDLER vdisk_fileio {
        DEVICE ram0 {
                filename /ramdisk/ram.img
        }
}
TARGET_DRIVER copy_manager {
        TARGET copy_manager_tgt
}

TARGET_DRIVER ib_srpt {

        TARGET fe80:0000:0000:0000:5849:560e:5c50:0401{
                enabled 1
                rel_tgt_id 1
                LUN 0 ram0
        }
        TARGET fe80:0000:0000:0000:5849:560e:5c50:0409{
                enabled 1
                rel_tgt_id 2
                LUN 0 ram0
        }
}
#TARGET_DRIVER iscsi {
#
#        enabled 1
#
#        TARGET iqn.2022-11.dev-debian-04.sn.1234 {
#                QueuedCommands 128
#                LUN 0 ram0
#                enabled 1
#
#        }
#
#}


　一度これでSCSTを起動します。systemctl start scst.serviceだとなぜかscst_vdiskが読み込まれないので、手で読み込みます

root@debian:~# for a in  scst scst_vdisk ib_srpt  ; do modprobe $a ; done


　その後、scst_adminで設定を直接読み込んで起動します。

root@debian:~# scstadmin -config /etc/scst.conf


　これでESXiにOFEDが入っていればそのうちディスクが見えるはずです。

ESXiからマウントして確認する


　LUNマスキングをしていないため、SRPが有効になったESXiがいるIBファブリックにつなぐと定期的にクエリが飛んでいるので勝手にターゲットを認識して未使用ディスクとしてESXiにマウントされます。非公式ながらSRPを使えるESXiは6.7U3が最終です。予め必要なセットアップをしたESXiから見てみます。スペックは以下です。

ターゲット
Dell T5810
CPU Xeon　E5-1620 v3
RAM 8*4GB @ 2133MHz (32GB)
HCA: Connect-IB@PCIE 3.0 x16接続 (デュアルポート接続)
RAMDISK 25GB

VMホスト
Supermicro X10SRL-F
CPU Xeon E5-2697 v4
RAM: 8*32GB@2133MHz (256GB)
OFED:MLNX-OFED-ESX-1.8.2.5-10EM-600.0.0.2494585
HCA: ConnectX-3　(not VPI/Pro) @PCIE 3.0 x8接続 ( マルチパス)


その結果が以下です。




　速い(確信)
　QDRなスイッチに接続されているため、理論値的には80Gbps*0.8 in MB/sで8GB/sが最大ですが、CX3がPCIE 3.0のx8でリンクしているため、PCIEの最大が64Gbpsとなり、それの0.8倍となると6.4GB/sが理論値になるのでかなり近いところまで出ています。もう少しIOPSが出てもいい気がしたので、以下のシステムでも検証してみました。

VMホスト

Supermicro C9Z390-PGW
CPU Core i5 9600K @ AllCore4.8GHz
RAM: 4*32GB@2666 MHz (128GB)
OFED:MLNX-OFED-ESX-1.8.2.5-10EM-600.0.0.2494585
HCA: ConnectX-2　 @PCIE 2.0 x8接続  (マルチパス)


　その結果が以下です。





　速い(確信)
　刺さっているのがConnectX-2というPCIE2.0の化石なので帯域は頭打ちになっていますが、CPUのクロックが高いのでIOPSがかなり出ています。

Connect-IBをESXiで使いたい人生だった


　Connect-IBはmlx5ドライバを使うため、6.7などでOFEDを入れても認識しません。しかし、デバイスにパススルーをかけてLinux VMでSRPを受け付け、そのディスクをもう一度内部のvmkスイッチとiSCSIで接続することによりストレージプロクシとして動かせば見えるのでは??というスケベ心が起きてしまったので試してみました。これが動けばESXiの上で動くドライバ依存がなくなるので、ESXi8も使えるようになります。センスのない絵にすると以下のような感じになります。SRPドライブはVMによりiSCSIに変換され、ESXiの内部ループバック接続によってDatastoreとしてマウントされます。




　結論から言うと、動くには動いたのですが、何故かPCIパススルーをかけたLinuxVM上からのSRPドライブに対してそもそもののパフォーマンスが出ないため、あまり意味がありませんでした。ddなどで負荷をかけるとSRPドライブそのものに対するアクセスが物理環境と比べて負荷が高いように見えました。
　とはいえ、ストレージプロクシ経由のESXi8.0環境でも1.4GB/sと10Gbps以上は出ていたので、何かしらのチューニングにより改善する可能性はあります。ただ、物理環境では問題なくてもパススルーVM環境だとib_read_bwが通らなかったりなど、なにか一癖ありそうな雰囲気がありました。起動オプションになにか必要なのかもしれません。
　また、SRPドライブをiSCSIでエクスポートし直してファイルシステムがこわれないのか、という疑問については問題ありませんでした。ただし、DEVICEの名前を元の名前と揃えておかないとESXiからマウントしたときのeuiが変わってしまうため、これを合わせる必要はありました。

root@debian:~# cat /etc/scst.conf
HANDLER vdisk_blockio{
        DEVICE ram0{ #←ここ
                filename /dev/sdb
        }
}

TARGET_DRIVER iscsi {
        enabled 1
        TARGET iqn.2022-11.dev-debian-iscsiloop.sn.1234 {
                allowed_portal 10.11.1.1
                QueuedCommands 128
                LUN 0 ram0
                enabled 1

        }

}


まとめ


　Connect-IBについてはIBで使う限りはなかなか良いのですが、ESXiについてはやはり6.7+CX3止まりということになりそうです。IBは損切りしたいのですが、いかんせん速いので結局これを使い続けることになりそうです。今どきのシステムだとハイパーコンバージドな構成でローカルに高速ストレージを積むのが流行りですが、自宅環境だと最低必要台数とハード構成の縛りが結構きつく、多少の冗長化を捨ててもコンピュートノードとストレージノードを分けられたほうがそれぞれに特化した構成が作れるので都合がいいことが多いです。

　とはいえ、そろそろNVMeOFとかiSER使いたいので誰か低消費電力な100Gスイッチください…

[ コメントを書く ] ( 388 回表示 )   |  このエントリーのURL  |  $star_image$star_image$star_image$star_image$star_image ( 3 / 266 )  |  
【HW/NW】SAXA SS3000で遊ぶ 
2022, March 25, Friday, 20:44 - PC, HardWare, Network
投稿者 @xmms



　 随分前にとある場所で「鉄(マテリアル)として廃棄する」というSAXA SS3000が大量にあり、試しに一つもらって遊んでみたところ、なかなか面白かったので鉄くずにするには惜しいと思い、更にいくつか買ってみました。(粗鉄として)　ハードウェア的にも超今更感ありますが、用途によってはまあまあ使えるので情報をまとめてみます。
　なにげにかなり更新をサボっていたので久々の更新になりました。WFHが始まってから文字を打つことが多くて、Blogを書く気力がわかなかったです…。

ハードウェア構成について


 CPUにはAtom C2338 が搭載され、そこにSoCから3本のGbEとPCIEから2本のNICが生えているファンレス構成です。MBは「CASwell, Inc. COB-H500」とありますが、CASwellのページには該当するような箱は見つかりませんでした。この手の箱は大体ホワイトボックスを作ってるメーカーから似たようなものが見つかるのですが、今回は該当しなかったので、箱の削り出しとカスタマイズをしているのかもしれません。強いて言うならCAF-1020がどことなく似ていますが、構成は全く違います。箱の質感も結構お金かかってる感じがします。

　ACは12Vで、もとは大きめの4Aのものを使うようですが、消費電力的には2-3Aくらい流せれば十分だと思います。ACアダプタは抜けどめを気にしなければ外形5.5mmで内径3.3mmの汎用的なものが使えます。内径が2.2mmではないので注意が必要です。

　Linux上の認識は以下のようになります。

owner@SS3K-VPN:~$ lscpu
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
Address sizes:       36 bits physical, 48 bits virtual
CPU(s):              2
On-line CPU(s) list: 0,1
Thread(s) per core:  1
Core(s) per socket:  2
Socket(s):           1
NUMA node(s):        1
Vendor ID:           GenuineIntel
CPU family:          6
Model:               77
Model name:          Intel(R) Atom(TM) CPU  C2338  @ 1.74GHz
Stepping:            8
CPU MHz:             1750.071
BogoMIPS:            3500.14
Virtualization:      VT-x
L1d cache:           24K
L1i cache:           32K
L2 cache:            1024K
NUMA node0 CPU(s):   0,1
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes rdrand lahf_lm 3dnowprefetch cpuid_fault epb pti tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms dtherm arat

owner@SS3K-VPN:~$ lspci
00:00.0 Host bridge: Intel Corporation Atom processor C2000 SoC Transaction Router (rev 02)
00:01.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root Port 1 (rev 02)
00:02.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root Port 2 (rev 02)
00:03.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root Port 3 (rev 02)
00:04.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root Port 4 (rev 02)
00:0e.0 Host bridge: Intel Corporation Atom processor C2000 RAS (rev 02)
00:0f.0 IOMMU: Intel Corporation Atom processor C2000 RCEC (rev 02)
00:13.0 System peripheral: Intel Corporation Atom processor C2000 SMBus 2.0 (rev 02)
00:14.0 Ethernet controller: Intel Corporation Ethernet Connection I354 (rev 03)
00:14.1 Ethernet controller: Intel Corporation Ethernet Connection I354 (rev 03)
00:14.2 Ethernet controller: Intel Corporation Ethernet Connection I354 (rev 03)
00:16.0 USB controller: Intel Corporation Atom processor C2000 USB Enhanced Host Controller (rev 02)
00:18.0 SATA controller: Intel Corporation Atom processor C2000 AHCI SATA3 Controller (rev 02)
00:1f.0 ISA bridge: Intel Corporation Atom processor C2000 PCU (rev 02)
00:1f.3 SMBus: Intel Corporation Atom processor C2000 PCU SMBus (rev 02)
01:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03)
02:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03)


 腑分けするとこんな感じです。







シリアルピンについて


　シリアルについては変態^H^H先駆者より情報をいただきました。このピンがシリアルピンです。白ポチより横にシリアルの1-5ピンに相当するので(3.3Vではない)通常のシリアルを適当なジャンプワイヤーなどでつなぐとOS上のttyS0にアクセスできます。




　ただし、uEFIへのアクセスはファームウェアにパスワードがハードコートされているため、通常はアクセスできません。




　先駆者がEEPROMをダンプしてパスワード解析をしていましたが、Boot方式をBIOS/MBRからEFIにできること、無効になってるTurboを有効化できる(300MHzあがる)こと、PXEなどを有効化できること以外は特にいじるところはない気がしました。まあ、TBも(排熱などの)理由があって無効化されているはずですし、有効化しても上がり幅が300MHzだと違いがほぼないので、uEFIに入る理由はほぼないです。。

　あとはSATAはコネクタを実装すれば使えるそうです。どれだけアンペアが引けるのか不明ですが、シリアルピンの並びにあるPROにちょうど5Vが来ているのでSSDの電源ソースにいい感じに使えそうです。SATAの横の未実装スルーホールは15Vと3Vだったので微妙にそのまま使えそうにはありませんでした。USBのピンヘッダもあるので、そっちから5Vを引けるかもしれません(こちらでは電圧を確認できませんでしたが…)




　それ以外にも色々ピンが生えているのですが、自分の知識では何がどれにつながっているのかまでは解析できませんでした。実はパスワードバイパスピンがあるのではないかといろいろテスタを当てながらショートさせてみたりしたのですが、結局謎でした。

各シリーズについて


　SS3kには無印/II/Proとそれぞれありますが、ハード的にはほぼ違いはなく、ProのみMiniPCIEより11nのWLANが生えているので、そのアンテナのためのSMA端子があります。また、搭載されているSSDにも何種類かあり、8GBモデルと16GBモデル、及びTranscend製MSM610シリーズとInnodisk製3ME2シリーズがあるようです。SSDの中身については完全に消去されてしまっていたため、OSの違いについては不明です。SSDについてはInnodiskのほうがデータシート上の耐久値は高いのですが、ddコマンドなどで連続書き込みすると途中でバッファ切れで失速するような動きをするので、Transcendのほうが動きは素直でした。まあ、どちらにしても期待するようなIOPSや帯域は出ませんが。ただ、後述のCPUエラッタがあるのでリカバリ観点からUSBからの起動を推奨します。

NIC周りについて


　かなりクソ^H^H混乱を招く構成になっています。ハードウェア的には、SoCから2本Marvellの88E6320に伸びており、それがそれぞれLAN2、LAN3となっています。88E6320をSoCのPHYを取り出すために使っていると予測しますが、その間が常に接続済みとなり、ケーブルを刺していなくてもLAN2とLAN3は常にUP扱いになります。そのため、ケーブルが抜けたことを検知できません。そして残りの1本が88E6176と接続されており、88E6176からハードウェアスイッチとしてLAN4-7があります。




　LAN4-7はNECのIXシリーズのように分割して扱うことはできず、Linuxであればenp0s20f1の下にぶら下がります。イメージとしてはBuffaloの小さいGbスイッチに繋がれている感じです。小さい構成だと時としてこの構成は使いやすいですが、VLANタグなどを一切使えないアクセスポートとして使う以上のことはできません。幸い、VLANを喋れる独立したポートが他にあるのでなんとかなりますが…。

　WANとLAN1についてはSoCとは別にPCIEにI211が生えている構成になります。注意しないといけないのはこのポートはバイパスポートになっており、SS3kの電源が切れるとリレーにより内部で結線されます。Softetherのtap/ブリッジのVPN専用ポートとして使うときなど、WANとLAN1を同じLANにつなぐようなことになるとループが発生するので注意してください。(1敗)　また、そのような構成のため、pfsenseなどを入れるときにはWANとLAN1を使うと思わぬ接続になりかねないので、バイパスされないWANとLAN2以降を使うことをおすすめします。LAN1/LAN2をOS上でブリッジさせ、そこにtcpdump/tsharkなどをかませてこっそりパケットキャプチャする、LAN1とLAN2でブリッジした上でNICごとに違うパケットフィルタルールを仕掛けて透過FWを作る、など、アイディア次第では色々できそうです。

　上記の構成をさらに混乱させる一番の問題は、OS上の認識順とポートの並び順がメチャクチャなことです。もともと他で使われることを想定していないので、勝手に蓋を開けられた上に想定外のOSをぶち込んでる外野にとやかく言われるのはいい迷惑だと認識した上でも、それにしてもどうしてこうなったのかという思いが強いです。特にLAN2-7はOSから見て常にLink Up扱いのためそれに気がつくまで無駄にあれやこれやとやってしまいました。

　初期値を画像にするとこうなります。見事に何一つ順番に並んでいません。どうしてこうなった…どうしてもこのクソ構成が気になる人はudevなどをいじって合わせてください。




Mini PCIEについて


　ProであればWPEA-121N/WというAtheros AR9382を搭載した11nのチップが乗っていますが、それ以外は空いています。シリアルの存在に気が付かなかったときは、mPCIEをPCIE x1に変換するアダプタと何故か転がっていたPCIE x1のMatrox G200を組み合わせて画面出力をしてアレコレしていました。

　




　ハーフmPCIEな拡張カードなら搭載できるので、なにかに使えそうではあります。

WLANについて


　WLANもせめて11acに対応できれば面白いとmPCIEな11acに対応した物を探したのですが、そもそも11ac(VHT)で5GHz帯にSSIDを吹こうとするとIntel系のチップはno-IR (no initiate radiation) フラグがファームウェアに書き込まれているため電波を発信することができず、Broadcomの場合はhost-apdに対応したx86向けドライバがプロプライエタリとして配布されているためSTAにしかなれず、Realtekの場合もno-IRが入っているようです。

　唯一の希望がAtheros/QualcommのQCA95xx, QCA98xx, QCA6300系チップを使ったものらしく、海外のフォーラムによるとMikrotik のR11e-5HacDがOpenWRTなどで使えるらしいです。まあ、ハーフサイズではないのでSS3kには入りませんが…。QCA系でも書き込まれているファームによってはW52帯でしかAPになれないものもあるようなので、組み合わせを探すのがなかなかに大変そうです。また、海外にはno-IRフラグを無視したドライバをビルドして使う方法もあるようで、その場合はIntel系チップでもAPになれるらしいです。

　個人的にはopen/dd dwrtでお手軽に作れればいいなくらいにしか思ってなかったのであまり詳しくは追ってませんが、どうしても11acのAPをx86で作りたい人は追ってみてもいいのではないでしょうか。




性能について


　2コアの1.7GHzプロセッサなので、そこまで高くはありませんが、LANの検証環境でOpn/pf senseでNATしてPPPoE接続した限り、1Gbpsくらいはさばくことができました。ただ、ntop-ngを動かすとFlowが少なくても全体の70%くらいを持っていかれてしまったので、あまり凝ったことはできません。それをしたいなら(Atom C3558+6GB RAMを搭載した)Sophos XG135あたりが性能的に必要になってくると思います。

　DebianとSoftetherを組み合わせ、電源入れるとおうちのLANをL2伸長する君をつくったときは、AES-NIが有効な状態でTLS_AES_256_GCM_SHA384アルゴリズムでレイテンシの低い環境なら大体400Mbpsくらいまでは出たので、ちょっとしたところで使う分には十分かなと思います。ファンレスなのでおうちのDS-Lite終端ルーターや、オークションでも安く出ていることがあるので複数買って雑にばらまくような使い方にはいいかと思います。

CPUのエラッタについて


　Atom　C2000シリーズと言うと誰しも頭に浮かぶAVR54バグですが、SS3kもエラッタ持ちのCPUリビジョンが使われています。というか、エラッタ持ちのCPUは2013年から製造され、解消リビジョンは2017年からの供給になるので、一部の長期供給メーカー以外には出回ってないと思われます。その間にC3000シリーズも出てるので、多くの場合は2017年の段階でこちらにシフトしているのではないかと思います。また、調べた限りリビジョンを調べるにはCPUIDが同じため実際にヒートシンクを外して刻印を見る以外の方法がないようです。

　実際に問題が出るかというと、この時期まで生き残っている筐体についてはかなり淘汰されたあとなような気がします。実際に来た筐体に関してはサンプル数は数十ですがほとんど問題がなく、1台だけ起動するとLEDがアンバーになりシリアルコンソールに何も出力されない(しかしOSは起動している)という物がありましたが、それ以外は特に問題がありませんでした。しかし、実際に問題が起きている筐体もあるという報告もあるので、なんとも言えません。

　いつ死ぬかはわからないので、死んだら他の筐体に入れ替えて継続できるように、いま動かしているものについてはUSBメモリで起動するようにしています。遠隔地においてあるので、死んだらケーブルとUSBメモリを差し替えて使ってくれ、と現地にコールドスタンバイをおいて運用しています。


まとめ


　信頼性がない状態からスタートなので壊れたらすぐに交換できるような予備機が必要ですが、ネットワーク系のおもちゃとして遊ぶにはいい箱だと思います。それ以外の用途だと、ストレージの搭載が限られるので、使い所が難しい気がします。NICはたくさんあるのでNFSなどでNASなどに逃がせればいいですが、単体で使う場合はせめてUSB3.0くらいは欲しくなります。mPCIEからUSB3を引き出せればまだ可能性はありそうですが…。あとはメモリを少し多めに搭載してk8sのクラスタなどを作ってもいいかもしれません。CPUがCPUなので、KVMを動かすのは厳しいと思います。
　全く無いようで少しだけあるハードの拡張性とその制限を考えながら、何かを作るためのおもちゃとしては面白いので、安価に転がっていたら手を出してみるのはありかな、と思いました。以上。

[ 1 コメント ] ( 582 回表示 )   |  このエントリーのURL  |  $star_image$star_image$star_image$star_image$star_image ( 2 / 707 )  |  

| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 進む> 最後へ>>