【HW】2ソケットマシンでゲームをする際のNUMA/パフォーマンスチューニング 
2019, July 19, Friday, 01:19 - PC, HardWare
投稿者 @xmms


　家の環境は所有しているメモリの量の問題で未だにXeon E5 v2環境から移行できないのですが、同じラインのCPUを長く使っているとアップグレードや筐体目当てのパーツ取りなどでサーバを買ったりして余剰パーツが増えた結果、使ってない資材同士が結合して新しいマシンが生えてきたりすることはよくあることだと思います。(そして日常的にハードウェアを入れ替えてると配線の綺麗さとかどうでも良くなってきて写真のような配線になります)

　そんなわけで、余ったパーツから生えてきたマシンを現在デスクトップ機として使っているのですが、2ソケットマシンをデスクトップ用途として使うとちょくちょくNUMAについて考えないといけない時があったのでまとめてみます。

環境


余ったパーツから生えてきたマシンは以下です。
マザボ　 X9DAi
CPU　Xeon E5 2667v2　*2
メモリ　DDR3 14900R 8*16　=128GB
グラボ　GTX 1080
その他NVMeとか10G-NICとか

　マザボについてはオークションで安かったので買ったのですが、サーバー用途で使おうとするとIPMIがないのはやっぱり使いにくいので結局本番稼働することなく部屋の隅に積まれていいました。
　しかし、Core i5 6600Kでマシンを組んだときに微妙に物足りなかったので、試しにX9DAiと余り物でデスクトップ環境を作ったらいい感じだったのでそのままこれを使っています。

　この環境を使っていても9割のことは困らないのですが、ゲーム時にパフォーマンスがばらつく時があったので、その対処法のメモです。

システムブロック図


　Xeon E5系/Ryzenから先はPCI-EがCPU直結になり、(AMD系ではThreadripper/Epicは)拡張スロットによって接続先のCPUが違う(AMDの場合はMCMのコアが違う)というのはパソコンオタクには常識だと思いますが、X9DAiのシステムブロック図は以下のようになっています。




　このことを意識してゲーム用GPUをCPU1に直結しているSlot1のPCIEx16に接続していたのですが、Windows/Linuxどちらであっても「実行するプロセスの使用する拡張ボードを考慮して」のNUMAの制御は今の所できません。

　そのため、CPUの混み具合によっては「本来ならCPU1で実行してほしいのにCPU2で実行されてしまって拡張ボードにアクセスするにはQPI/Infinifablicを跨いでCPU1経由でアクセスしなければならない」ということが起きます。

　Xeon 5600系まではどちらのCPUであってもPCH経由でPCI-EにアクセスしていたのでどちらのCPUもどのボードに同じコストでアクセスできたのですが、QPIの限界が来てしまったのでCPUに直結された結果、このような微妙に不便なことが起きます。

Windows10でのNUMA


　Windows10でもNUMAを意識してくれるのですが、だいたい重要なプロセスがCPU1で実行されるため、ゲームなどは空いていることが多いCPU2で実行されてしまいます。しかし、そうなってしまうとGPUからは遠くなってしまうので、できればCPU1側で実行してもらいたいのです。

　見ている限りだと、CPU1とCPU2両方をフルに使って実行されるゲームはなく、すべてのコアで実行を許可しても、どちらかのCPUのすべてのコアのみで実行されていました。

CPU affinity


　もともとはNUMAの出始めの頃のサーバープロセスやDBプロセスのパフォーマンスチューニング手段でしたが、現在でも40GbE/100GbEなどの広帯域インターフェースを使う際にインターフェースに近いCPUでの実行を強制するために有効です。
　ちなみに、現在のOSは賢いので極端なプロセスでなければ設定しなくてもNUMAノードのCPUやメモリの空き状況を見て、余裕がある方によしなにNUMAをまたがないようにプロセスを振り分けてくれます。

ゲームプロセスにCPU affinityをかけたい


　プロセスのアフィニティー自体はタスクマネージャーの詳細の中にある「関係の設定」より簡単にかけることができるのですが、ゲームプロセスなどの場合、チート防止などの理由により起動後にアフィニティーを変えることができないことが多々あります。

　その場合どうすればいいかと実験したところ、アフィニティーがかかったプロセスから子プロセスを実行するとアフィニティーが伝搬するので、steamなどを

start /affinity ffff steam.exe


　で呼び出し、その伝播したSteamから更にゲームを実行すると最初からアフィニティーがかかった状態でゲームを開始できるようです。

　しかし、これでうまくいくものもあればメニューの変なところで止まるものもあったため、結局Steamにアフィニティーをかけるのはやめました。

CPU2を混雑させたい


　ゲームにアフィニティーをかけるのが問題であれば、自動選出の結果CPU1が優先的に選ばれるようにしたいので、逆にゲームに関係しないどうでもいいプロセスをCPU2側で実行させて意図的にCPU2を混雑させることにしました。

十進数でアフィニティーを確認する


　このあとのPowershellでまとめてアフィニティーを設定したいので、まずnotepadなどを起動し、タスクマネージャーからCPU2を使うように手動でチェックを入れ、アフィニティーを設定します。




　CPU2(ノード1)側をすべて使用するように設定したら、PowerShellでアフィニティーの値を取得します。もちろん関数電卓で直接やってもいいのですが、間違うことがあるのでこの方法が楽です。

PS W:\> Get-Process notepad|Select ProcessorAffinity

ProcessorAffinity
-----------------
4294901760

　4294901760というのは32スレッドのうち、奥の16スレッドを使用するという定義で、関数電卓に入れバイナリ値を見るとわかりやすいです。




　ちなみに、PowerShellだとアフィニティーの指定は10進数ですが、start /affinityだと16進数になるので、古くからあるstartコマンドで同じことをしようとすると

start /affinity ffff0000 otepad.exe

　になります。

邪魔なものをどかす


　これから実行するプロセスをすべて特定のアフィニティーをかけて実行したい場合、まずcmd.exeをアフィニティーかけた状態で立ち上げ、一度explorerを taskkill /im explorer.exe /fなどで殺したあと、explorerと実行するとcmd.exeにかかっていたアフィニティーでデスクトップ環境が立ち上がります。

　そのエクスプローラから実行されたプロセスもアフィニティーが伝搬していくので、デスクトップのアイコン等をクリックして実行してもアフィニティーがかかった状態で実行されていきます。

　停止できないプロセスについては、管理者権限で実行したpowershellで

foreach($p in "SearchIndexer","OfficeClickToRun","sqlservr","sqlwriter"){ ForEach($PROCESS in GET-PROCESS $p) { $PROCESS.ProcessorAffinity=4294901760} }

　などと実行するとアフィニティーをまとめて変更できます。ただ、svchostやdwmなどはアフィニティーをかけるとOSが不安定になることがあるので、変更しないほうが良いようです。また、CrystalDiskMarkなどもアフィニティーがかかっている状態だと正しく実行できませんでした。

　また、どのコアでどのプロセスが暴れているかを見つけるには Process Explorer を使うといい感じに見つけられます。




　大体の場合、ブラウザ(ChromeやFirefoxなど)をCPU2側で実行しておけば(特にマシンをシャットダウンせずに放置するような環境の場合)メモリ使用量などの関係で「CPU2は混んでいる」となるようです。

ゲームを実行してみる


　アフィニティーのかかっていない状態のSteamなどからゲームを起動します。その後、CPU1側が優先的に使われるようになったら成功です。




　それでもまだCPU2が使われる場合はCPU2のしばきが足りないのでいろいろ実行してください。

　CPU2側でゲームを実行されると、特にオープンフィールドなゲームでマップが広くメモリ使用量が多いゲーム(GRWとかArkとか)を実行すると、CPU2側からQPI越しにGPUになんか転送してるんだろうなというような一瞬のフリーズが起こることがちょくちょくありました。しかし、CPU1側で実行を強制するとそれがだいぶ軽減されました。
　また、ブラウザをCPU2側で実行するとどれだけブラウザが重くなってもゲームに影響しないので、それはそれで2ソケットの使い分けとして便利な気がします。
　そもそもXeonはゲームするようなプロセッサではないというのは尤もですが…。

　マシンを新しくしようかどうか悩むところです。

[ 2 コメント ] ( 1978 回表示 )   |  このエントリーのURL  |  $star_image$star_image$star_image$star_image$star_image ( 3 / 1431 )  |  
【HW】SRPの速度テスト 
2019, March 8, Friday, 05:22 - PC, HardWare
投稿者 @xmms
　前回のエントリでHCAより先にPCI-Eの帯域が限界に来ていたことに気がついたので、HCAを2枚使ったらどうなるかをテストしてみました。今までDualportでもまあこんな速度かと思っていたのですが、よくよく考えたらPCI-Eがネックになっていたという…。SRP自体使い始めてからかれこれ5年ほど経過しますが、ほぼ情報がない(≒誰ももう使ってない)ので悲しみと今後iSERを使ったときの比較用のメモとして残します。

セットアップ


テスト環境はこんな感じです。


　ストレージサーバ　RX300S7
　
CPU Xeon E5 2643*1
Mem 8GB*8 at DDR3 1600MHz
Drive SanDisk Optimus Ascend 800GB *10 /RAID5 for Data (PN:LN0800FEHDC)
RAID HBA D3116C (MegaRAID SAS 2208@PCI-E 3.0)
IB HCA MT26428 (Connect-X2 VPI Single Port QDR) *2@PCI-E 2.0
Target SCST Version 3.4.0 from git repo

　LIOでもSRPターゲットを作れますが、負荷が1つのコアに集中する、たまに刺さる、認証なしのターゲットが作れないといったことを経験したのでSCSTを使っています。SCSTは非常に安定していて、3-4年位使っていますが問題ありません。ストレージ側の設定はこんな感じです。
# cat /etc/scst.conf

HANDLER vdisk_fileio {
DEVICE dev-srp0 {
filename /vdisk/srp0.img
}
}

TARGET_DRIVER copy_manager {
TARGET copy_manager_tgt {
LUN 0 dev-srp0
}
}

TARGET_DRIVER ib_srpt {
enabled 1
TARGET fe80:0000:0000:0000:0002:c903:000f:41a7 {
enabled 1
rel_tgt_id 1
LUN 0 dev-srp0
}

TARGET fe80:0000:0000:0000:0002:c903:000f:8395 {
enabled 1
rel_tgt_id 2
LUN 0 dev-srp0
}
}


　仮想ホストの環境は以下です。SRPを使う手順はこちらを参考にしてください。
DL380p gen8 ESXi 6.5


CPU Xeon E5 2667v2 *2
Mem 16GB*16 at 1333MHz
IB HCA MT26428*2 (Connect-X2 VPI Single Port QDR)


　仮想マシン
Windows 10 x64 Pro 1809
vCPU 4
Mem 6GB
ベンチマーク用のディスクには準仮想化SCSIコントローラーを使

　この状態で、ディスクへのパスを切り替えてテストします。 テストには最初 IO Meterを使おうと思ったのですが、パラメーターによって大きく値が変わってしまうので再現性のあるCrystalDiskMark6.0を使用しました。

ストレージ接続*1本


　まずは、1ポート接続でテストします。


　接続図はこんな感じです(途中のIBスイッチは省略)



　その結果が以下です。


　読み、書きともに120-130kIOPSで、帯域は3148MB/sでした。

ストレージ接続*2本


　次に、接続を増やしてテストします。ラウンドロビンの切り替えは1IOごとに行う設定にします。
esxcli storage nmp satp rule add -R gsan -s VMW_SATP_DEFAULT_AA -P VMW_PSP_RR -O iops=1

　設定ははこうなります。


　接続図はこんな感じです(途中のIBスイッチは省略)



　その結果です。


　読み込み250kIOPS、書き込み150kIOPS出ました。また、帯域は読み込みに関してはきれいに2倍にスケールしました。いくらほぼストレージサーバのRAMへの読み書きとはいえ、びっくりするほど速いです。こんな速かったのか…。
　また、読み込み250kIOPS時のストレージサーバの負荷はこんな感じでした。


　 何かのエージェントで監視しているわけではなくnmonで見ていましたが、これより大きく外れることはありませんでした。

まとめ


　SRPはもはや旧世代なハードウェア、かつ4コアという、今となっては非力な環境でもかなりの性能を発揮できました。もちろん、搭載しているRAMがちょっと多いのでDirtyやキャッシュの助けもありますが、nvmeのような高速なストレージを使ってもSRPはネックにならないというのはかなり強いです。
　とはいえ、これを目当てに今からInfinibandを入れるのは、サポートの切れたConnect-X2からCX3世代をサポートの切れたドライバで動かすという、あまりにも将来性がない構成になるのでおすすめしません。
　iSERは試したことがありませんが、原理としては同じなので今からやるならせめて40GbEのiSERでしょうか。100GのiSER環境も試してみたいのでどこかにスイッチとNICが転がってないかなと思う日々です。

　早くこれよりも超高速なストレージを見つけて将来性のあるモダンな構成に移行したい…

[ コメントを書く ] ( 880 回表示 )   |  このエントリーのURL  |  $star_image$star_image$star_image$star_image$star_image ( 3.1 / 1868 )  |  
【HW】最速のストレージを求めて… 
2019, March 1, Friday, 01:03 - PC, HardWare
投稿者 @xmms
　家で仮想化基盤を扱っていると、どうしてもネックになりがちなのがストレージです。特にWindows環境での検証やVDIのテストをしていると、どうしてもIOが多いのでストレージがネックになり、あまりに遅いと作業のやる気が失せてしまいます。
　このIOが遅いというのが嫌で仕方がないので、家で使えるレベルでの最速のストレージを求めて今までいろいろなことを試してきましたが、そのあれこれを雑然と書きたくなったので書いてみます。あくまでも家で使うレベルの話であり、業務でやるなら各ベンダから出ているオールフラッシュストレージをサポート付きで購入してください。

階層化ストレージ


　今でこそSSDは容量も増え価格も下がりましたが、2017年位までは500GB以上のSSDとなるとなかなかの価格でした。そのため、それまではHDDのみの構成でしたが、128GB-256GBが手頃になり始めた2016年位に階層化ストレージとしEnhance-IOを入れてみました。ただ、メインストレージには日々(使用領域をほぼ舐める)バックアップが入ってしまうため、サイズの小さいキャッシュだとHOTなデータが流れてしまう事が多く、ヒットレシオは30%くらいでした。




　その後、ES3000v2というエンタープライズなPCI-E SSDが数枚手に入ったのでこれを VMware上の仮想マシンクローニングを高速化するためにライトバックキャッシュにしたかったのですが、ライトバックキャッシュとして使おうとするとhioドライバ (Fusion IOのドライバ名を真似している)の上がってくるタイミングとudevがenhance-ioのキャッシュセットを組み立てるタイミング、fstabをもとにOSがディスクをマウントするタイミングなどが合わず、ライトバックキャッシュとして使うとファイルシステムが壊れるという事態が起きました。




　また、常にFPGAを全力で動かすことによりレイテンシを削減しているため、省電力機能といったものがなくカード自体が非常に発熱します。拡張カード周辺はかなり強い風量で空気を循環させないと、複数枚刺したときにOver Temperatureのログ出力とサーマルスロットリングを受ける状態でした。室温が常に18度というような環境であればいいのかもしれませんが、人が生きる環境だと春以降温度が上がるため厳しいです。
　確かに性能はnvmeがなかった当時としてはかなり高かったかもしれませんが、発熱量とドライバと消費電力量的にちょっと使いにくいのでどうにかしたい思いが強くなりました…。ドライバについては、Debianでも問題なくソースからドライバをコンパイルすることによって動きましたが…。




　そしてちょっと前に、3.2TBのSSDが数本手に入ったので50TBのディスクの前段キャッシュにしようとしたのですが、ここであることにハマりました。キャッシュのメタデータ保持に4Kページ使用時でSSDの容量の0.1%程度のサイズのメモリを消費するのですが、RAID5などでまとめた実効9TBのSSDとなると、メタデータのために9GBのRAMが必要になります。RAM自体の空きはあったはずなのですが、メタデータが巨大になると、それをメモリ上に展開するのに非常に時間がかかるようになり、起動時のキャッシュの組み上げ時にランダムにカーネルが刺さってpoweroffもできなくなることがありました(つまり電ぷち)。

　検証の結果、WBで使う場合にはキャッシュサイズが大体2TBを超えてくるとfstabではなく自分のスクリプトでマウント(及び付随するサービスの起動)をどうにかする必要が出てきて、またSRPのようなブロックデバイスアクセスだとそもそも思ったようなキャッシュの動きをしてくれなかったので、最終的に諦めました。NFSだったらまたキャッシュのヒットも違ったのかもしれませんが、あまり大きすぎるサイズのキャッシュが来ることを想定していないようでした。もっと前に検証で気がつけた部分もあるのですが、いざそのときにならないとわからない部分もあるのです…。
　bcacheも試したのですが、こちらは思ったほどいい動きをしませんでした。

結局


　SSDだけでも結構な容量なので、検証に使うSSDなLUNと、データ保存に使うHDDのLUNを分けることにしました。HDDのLUNでもストレージサーバ側のメモリキャッシュが効くので、データがホットな分にはHDDでも十分なのですが、VMのクローニング時には読みと書き込みが1つのLUNに同時に走るので、接続が全二重なSAS-HDD(NL-SASですが)といえどバックの性能差が顕著に出ます。

　SSDはベンチマーク的に良かったSmartArray P420にキャッシュとキャパシタをつみHW-RAIDにしました。P420もHPE以外のマシンで使おうとするといろいろ苦労がありましたが…。経験的にエンタープライズクラスのSSD(IntelのDC3610とかMicronのM5000DCとか)は壊れたことがないので、おそらくフラッシュメモリ部分の劣化が来ることはないと思うのですが、過去にコンシューマSSDでコントローラー側の故障と思われる原因でSSDが見えなくなったことが何度かあるのでRAID5を選択しました。ただ、パリティでSSDの3TBが持っていかれるというのがなかなか気分としてつらいです。RAID0でも良かったのではと思わなくもないですが…。

ストレージマシンにメモリマシマシ


　これは手っ取り早く効果が出ます。特にメモリがある程度大きいマシンで、ストレージ以外に仕事をさせない前提なら/etc/sysctl.confで
vm.dirty_background_ratio = 35
vm.dirty_ratio = 90

とメモリの90%位を書き込みバッファにしてしまうとわかりやすく速くなります。ストレージサーバだけで128GB位メモリを持っているとほぼオンメモリで動く上に、VM上でごちゃごちゃ書き込んだとしても最終的にXFSの遅延書き込みによりシーケンシャルになるので、SSDにも優しいです。多分。当然、突然のシャットダウン時にデータを損失する可能性はありますが、全損してもデータ自体は違う筐体から最短1日前に戻せるのでそれは許容しようかと思いました。崩れても誰にも怒られないので、それよりは性能を重視したいです。(ただし何かあったときに誰の助けも受けられないので血を吐きながら泣いて復旧作業をしなければならない)

ストレージ接続


　 現状Infiniband+SRPを超えるものが見つかりません。非公式ながらESXi6.5でもSRPは動きますが、Mellanoxのディスコン扱いがひどいのでなにか別の手段を探そうとしているのですが、結局これを超えられません。助けて…

　8GFCのIOPS性能に夢を見た時期もありましたが、FCターゲットをLinux上に作ろうとするとHBAをイニシエーターからターゲットモードに変更するという手間や、苦労して作った割に10G iSCSI/NFSのほうが総合的に性能が良かったりFCターゲットは負荷をかけると刺さったりしたので、FCターゲットはベンダから買うものであって作るものではないと実感しました。SCSTのFCターゲットは試していないのですが、もしかしたらこっちはLIO/targetcliの環境で起きたようなことはなかったかもしれません…が、もうスイッチ含めて手放してしまったので検証できません。

　いくら10G-iSCSIでも、レイテンシやIOPS的にSRPのそれには追いつきません。SRPの代替としてはほぼ同じ原理のiSERがありますが、40G Etherを入れて初めてIBのSRPと渡り合えるレベルなので、それ以下の25GbEなどではせっかく環境を揃えても純粋なストレージインターコネクトとしてはデグレになってしまいます。
　100G EtherのスイッチとNICが手に入ればいいのですが、HCAが3000円で買える上にRDMAできっちり40Gbpsが出るIBに比べると、いま時点のパフォーマンス観点からの選択肢としてはIBに歩があります。ただ、IB自体が特に仮想化ではディスコンの流れをたどっている部分があるので、あまりこれにベッタリするのもやめたいのですが…移住先がない…。




　どの程度の性能かというと、1ホスト1LUNで160kIOPSの性能が出せ、帯域面では3.3GB/s程度出ます。ほぼストレージサーバーのメモリへの読み書き速度ですが、VMホストから見てもIOPSのカウンタは回っているためVM内のメモリ書き込みではなく、しっかりとHCA経由でIOがやり取りされています。
　デュアルポート接続なのでもう少し帯域を出せないかと思いましたが、そもそもPCI-Eの2.0のx8が500MB*8レーン=4GB/sであり、IBの8b/10bエンコードを考えると4GBの80%なので3.3GB/sというのはほぼ理論値でした。1HCA/DP構成ではなく1ポートHCA*2の接続にするか、PCI-E 3.0対応のCX-3以降に置き換えればPCI-Eの帯域が倍になるのでもう少し出ると思うのですが、未検証です。複数HCAのIO分散は気になるのでいつか試してみたいです。

まとめ


・ストレージを強くしたいならbcacheやeioなどの階層化ストレージに夢を見ずにフルSSDやnvme構成にするのが一番シンプルで速い
・それ以上を求めるなら多少の耐障害性を落としてもメモリを許されるだけ乗せるしかない
・IB+SRPは間違いなく速いが、いろいろノウハウがいるうえに仮想化周りではIB自体が鎮火しているので今からIBに投資するのはやめたほうがいい
　・NFS over RDMAとか今からIBで再流行しないかな…だめかな…
・vSANは…うん、それもまた人生だね!

　今の流れとしては分散型のスケールアウトストレージ+賢いローカルキャッシュというものがイケてる構成ですが、主に電力事情で動かせるマシンが限られてくると1つのマシンをいかに強くできるかというスケールアップ型になってしまいます。
　この構成だとストレージの冗長構成が取れず/取ろうとすると非常に厳しく、何かしらでストレージが不意にクラッシュすると即死ですが、これはこれで普段切り分けしやすいという点で使いやすい面もあります。
　スケールアウト型を車で例えるとトルクベクタリングなど次世代の仕組みを組み込んだ車ですが、SRPなどはシンプルに基礎を抑えていて低回転域から高回転域まできっちりトルクの出る大排気量車のようなものです。それぞれにいい悪いはあるのですが、後者は時代の流れによりディスコンなのが悲しいです。
　無限に電気を使えれば無限にマシンを増やしてスケールアウト型のストレージなどにも手を出したいのですが現実は厳しいです。

完全に趣味の話でした。おしまい。




[ コメントを書く ] ( 618 回表示 )   |  このエントリーのURL  |  $star_image$star_image$star_image$star_image$star_image ( 3 / 1548 )  |  
【HW】新しめのFortigateに使われてるACを自作する 
2018, December 26, Wednesday, 01:06 - HardWare, Network
投稿者 @xmms
　かなり更新をサボっていたので久々の更新です｡Confluenceもメモ書きとして契約してしまっているのでこのブログをどうしようか悩んでいるのでいるのですが、しばらくは生かしておこうかと思います。さて、ちょっと前に秋葉原で捨て値で売っていたFortigate　40Cをいくつか買ってみたのですが､ACが付いてこなかったためつくってみました｡




　まず､このコネクタの名称の知識がなく調べる手がかりがなかったので､Googleの画像検索やら各レセプタの形状や名称一覧などを大量に調べました｡その結果､どうやらMolex 5557の4.2ミリピッチというコネクタがそれっぽいようでした｡


　コネクタやコンタクトピンについては､千石通商などに売っているようなのですが､SonicwallのAP(TZ-100)にも同型のコネクタが使われていて､そのACで基本的な動作確認が出来てしまったので｢急ぎでもないし、より安価なモノタロウで何か買うついでにいつか買おう｣と放置していました｡(ちなみに買った時点ではぎりぎりライセンスが生きていたのでOSのアップグレードが出来ました｡)　そして先日､諸々を買う機会があったのでついでに興味本位で買ってみました｡




今回買ったコネクタとコンタクトピンは以下の二つです｡
Molex 5557コネクタ　5557-02R-210
https://www.monotaro.com/p/0856/1585/
コンタクトピン　5556T3L
https://www.monotaro.com/p/7593/9272/

コネクタについてはより安いこっちでもよかった気がします｡
https://www.monotaro.com/p/0856/1472/

　とりあえずコネクタだけ形状が合うか確認しましたが､これであっているようでした｡




　次に､起動できるACの極性を確認しましたが､爪がある方が+でその下がｰになっているようです｡




　極性が分かったのでピンをかしめていこうとしたのですが､専用の圧着機がないとつらいです｡最終的にニッパーでかしめる技術を習得しましたが､何回かピンからケーブルがすっぽ抜けてブチ切れそうになったので､今回はやりませんでしたがハンダで軽くとめておくのが確実な気がします｡(圧着とは…)

　絶縁のために(ビニールテープが見つからなかったので)養生テープで根本を軽く巻いたのですが､これが失敗でした｡ただでさえコネクタの奥までピンを押し込むのが大変なのですが､このテープのせいで余計やりづらくなりました｡電子工作になれている人やもっと几帳面な人であればこんなことをしないと思いますが､動けばいいだろ位な雑な気持ちでやった結果､無駄な苦労をしました｡




　なんとかピンを奥まで押し込んでピンがロックされたことを確認したので､ちゃんとコネクタ内部のピン同士が接触していること､逆接になって爆発しないことを祈りながらACに繋いでみました｡




　すると､電源の容量不足やピンの接触が甘いといったこともなく､爆発せずに無事起動してきました｡コネクタからピンのすっぽ抜け防止に紫外線硬化樹脂などで後ろを固めるのがよりよいと思いましたが､必要な物を買うと割と高くなるうえに買っても使うことは多くなさそうなので今回は見送りました｡

　作った感想ですが､コンタクトピンの圧着器を持っていないのであればおすすめしません｡その辺の工具で済ませようとすると器用さというかコツが必要です｡ラジオペンチやニッパーで代用は可能ですが､慣れるまでピンを4本無駄にしました｡また､AC自体はオークションなどで1000円前後で売っているので､必要であればこっちを買うべきです｡

　ただ､自分のようにジャンクでAC無しのFGをいくつか拾って､しかもACをいくつか欲しいけどACが本体より高いし12VのACは大量に余っているので自作したい､という貧乏な考えがあるのであれば作るというのも一つの手ではあります｡
　しかし､カシメが不十分でケーブルがすっぽ抜けたりピンがしっかり奥まで入っていないためケーブルを動かすと接触不良で電源が落ちる､という事が起こるので(実際に起きて作り直した)､作ったとしても精々検証用にとどめておくのをおすすめします｡

　ちなみに、このFGはFlets網内のv6折返しのテストに使おうと思っていたのですが、FortiOS 5.2だとIPv6の自動設定にDHCP6-PDやSLAACが使えず、かつNP6を搭載していないためv6の通信がCPU処理になってしまい残念なことになった(LAN内のv6NAT通信で200MbpsくらいでCPUが張り付く)ので、v6関係は諦めVDOMが使えた頃の軽量な4.0MR3に戻しました。v6のSNATができたのは良かったのですが…残念。

[ コメントを書く ] ( 808 回表示 )   |  このエントリーのURL  |  $star_image$star_image$star_image$star_image$star_image ( 3.1 / 1418 )  |  
【HW】HUANAN X79を買ってみた 
2017, May 4, Thursday, 00:49 - PC, HardWare
投稿者 @xmms


　最近はRAIDカードの検証などであれこれしていたのですが、その際にPCI-E 3.0でリンクでき、かつ自由に再起動できる遊んでいる資材が、自分の環境にはもらったGA-X79-UD-5とHPのML350pGen8しかありませんでした。
　しかし、ML3530pはサーバにありがちな再起動に2分3分かかるのが苦痛なのと、物理的なアクセス(積んでいる場所)の制限によりカードの差し替えがつらいと言う問題があり、GA-X79-UD5に関しては10G+FCoEなCNAなカードや、ほぼ全てのRAIDカードなどのオプションROMを持った拡張カードを挿すとPOSTしなくなるという問題がありました。

　なので、そろそろたたき台の板を更新しても良いかなと色々見ていたところ、謎のHUANAN X79というMBがオークションでXeon 2660v1とRegECCなDDR3メモリ4GBx4がついて2万円だったので、怖い物見たさと知的好奇心で買ってしまいました。そのメモを色々雑に書いておきます。
　更新する先が2011v1と言うのも残念ですが、DDR3メモリやらなんやらが余っているのでDDR4に移行できないという…。

べつに宣伝をするわけではないので、気になった人は各々探してみてください。
余談ですが、最初HUMANと読みましたがHUANANなので検索するときは注意してください。

内容物


　SATAケーブル、IOシールド、マニュアル、ドライバCD、Xeon 2660v1とRegECCなDDR3メモリ4GBx4、そして何故か親切にもCPUのサーマルグリスがついてきました。使いませんでしたが。
　Xeon 2660v1はどうやら正規品らしいです。CPU-ZやSR0KKというSスペックを信じる限りは…。




　メモリは、サーバでよく見るSamsungのDDR3 RDIMMでした。壊れていたら文句を言おうかと思ったのですが、Memtest86を2周してしまったので諦めます。

　マニュアルはフロントパネル用ピンヘッダの配置と、OSへのドライバインストールなどをさらっと書いた程度の物(中国語)であり、Supermicroのような細かい接続ブロックダイアグラムは一切ありませんでした。

外見


　リア端子は必要最低限、基板は割と堅い構成に見えます。




　オンボードに謎のm-SATAコネクタがあるのですが、WifiなどのPCI-Eカードが刺さるのか、mSATAを使った場合オンボードのSATA3ポートのどちらかと排他になるのか、その後ろにあるジャンパピンは何なのか、どこにも何も書いてないので謎です。

起動できるCPUについて


　XeonのES品・QS品、V1/V2何でもいけました。



　確認した限りの最大構成では、興味本位で買った12コアの2696v2のES品と、メモリも16GBのDDR3-1333Rx4の64GBまで確認しました。

　X79で何故RDIMMがいけるのか謎で仕方がありませんが、CPU側にメモリコントローラを搭載しているからなのか、Welcome to ようこそ謎チャイニーズテクノロジーなのかはわかりません。
　実はUD-5もv1のXeonに関してはES/製品版が起動できるのですが、RDIMMは認識できません。 このX79でもi7の3900/4900系を載せたら多分RDIMMは動かない気がしますが、未確認です。

その他



　BIOSのリビジョンは4.6.5で、最終更新はこの記事を書いた時点で半年前の10月でした。




　X79にしては息が長い気がしますが、公式製品ページが見つからないためBIOSのアップデートがどこから手に入るのかは謎です。

　CPUのヒートシンクにはZalman FX70と言う物を利用しました。
　まあじゃんぱらでたまたま安いのが見つかったのでこれにしたのですが、中々に芸術点が高い作りをしています。芸術的な作りが故に、持ち上げるときに左手小指と右手親指の2回指を切っているので、扱うときは気をつけましょう。

　グラボはかれこれ長く使っている(500円で数枚買った)Matrox G550のPCI-E x1版を使って検証しました。どうせリモート(RDP/IP-KVM/SSH)で作業してしまうので起動画面さえ見えればいいと言う割り切りさえすれば、貴重なx8やx16レーンを使わずに普段余るx1にグラフィックを回せるので、この手のマザボ使用時の検証用途には安く手に入ればおすすめです。
　ただしWDMなグラフィックドライバが出ていないのでWin8以降はドライバがあたりません。Win8以降は標準ドライバでそれなりに動きますが、間違えてメイン機で使おうとすると大変なことに…。


まとめ


　謎なMBですが、オンボードデバイスが必要最低限になっているためか、カードとの相性もなく癖のない動きをしています。が、信頼できるかというと怪しいので、目の届く範囲外での使用は避けたい気もします。

　しかし、良いか悪いかは別として、ES品が動いてしまい、かつ余ってる/割と安価に買えるRDIMMも使えると言う魅力もあるので、一概にダメとも言えないのが悩ましいところです。

　なので、物好きな人が、知的好奇心を満たすために自己責任で試す分にはいいと思います。

以上です。



[ 2 コメント ] ( 2712 回表示 )   |  このエントリーのURL  |  $star_image$star_image$star_image$star_image$star_image ( 3 / 1856 )  |  

<<最初へ <戻る | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 進む> 最後へ>>