-
グラボを分解清掃した話
会津ラボの阿部です。普段はバックエンドエンジニアをしています。今回は手持ちのグラフィックボードを分解清掃・改造したお話です。 はじめに 今回使用するのは GeForce RTX 3060 12GB です。2021年発売で少し古いですが、メモリが多いためまだまだ現役です。 NVIDIA GeForce RTX 3060 12GB発売：2021年メモリ（VRAM）：12GBTDP（消費電力）：170W処理性能：PS4 < PS4 Pro ≈ Xbox Series S < RTX 3060 < PS5 ≈ Xbox Series X※ 処理性能比較は大まかな目安です PCゲーム用途では非常に普及したモデルです。昨今のAIブームに関連してPCでAIを動かすローカル推論に使うこともできます。 運用上の問題点 一方でこの個体に特有の問題があります： 原因を分析してみます： 原因から解決方法を考えます： 今回のゴールは以下の2点です： ⚠️免責事項⚠️ 当然ながらグラフィックボードの分解は保証や修理が受けられなくなります。行う場合は自己責任で 本題 工程ごとの写真は撮り損ねたため、写真がない工程は雰囲気でお伝えします。 分解 ファンやヒートシンクを取り外し、基板むき出しの状態です。青っぽい基板の上のチップがGPUで、その周辺にある6つの黒いチップがメモリですね。 ヒートシンク側です。この鉄板がGPUに密着して放熱します。サーマルパッド（熱伝導シート）がメモリや他の発熱する部品に接触するようになっています。GPUだけでなくいろいろな部品が発熱するため、複雑な形状になっています。 ・・・よく見るとGPUとヒートシンクが接触する部分にサーマルパッドが貼ってあります。つまりこのモデルはGPUグリスを使っていないようです。サーマルパッドも経年劣化で熱伝導性が下がるため、交換が必要です。 GPUグリス塗布 グリスを目一杯塗布しました。サーマルパッドの代わりにGPUとヒートシンクの間を埋めるように塗ったため、非常にたくさん塗ることになりました。当然ながら非推奨です。グリスは本来もっと薄く塗ります。 一応このまま動作テストしました。温度的には5度程度改善しましたが、根本的な改善が必要そうです。 GPUがヒートシンクに密着するよう加工 GPU-ヒートシンク間の距離が短くなるよう、ヒートシンクの足部分（プレートにある4箇所）を金属ヤスリで削ります。 ファンのケーブル配線とファン取り付け 取り付けるファンはPCケース用の140mmファンです。本来は変換コネクタが必要ですが、今回は既存品を流用します。GPUファンのケーブルを切断し、PCファン用のコネクタをはんだ付けします。 ご参考として変換コネクタのイメージです。「gpu ファンケーブル」で検索すると見つかります。 ファンをヒートシンクに結束バンドで固定します。無骨ですが機能十分です。 パフォーマンスの確認…
-
会社サーバーPCの内部を清掃した話
会津ラボの阿部です。普段はバックエンドエンジニアをしています。今回はホコリまみれだった会社のサーバーPCを掃除したお話です。 はじめに 古いサーバーPCにホコリが堆積してきたため掃除します（今更）。７年程度メンテナンスされていなかったようで、かなりホコリが堆積しています。 今まで掃除されてこなかった理由はいくつかあります。 今までだましだまし使ってきましたが、グラフィックボードをフルで回すとサーマルスロットリングが発生していたためお掃除を敢行します。サーバー機は停止しても問題ありませんでした。 サーマルスロットリングCPU、GPU、SSDなどのパーツが許容温度を超えた際に、故障を防ぐため自動的に動作周波数や電圧を下げ、パフォーマンスを意図的に低下させる保護機能です。 お掃除戦略 ギャラリー 作業していると楽しくなって写真を撮り忘れることが多々あります。ご了承ください。 ホコリまみれのCPUクーラー。エアダスターでホコリを飛ばします CPUグリス再塗布。少し多めに塗布してしまいました CPUクーラー装着 ホコリで目詰まりしているグラフィックボード グラフィックボードを分解しようとしたらネジが錆びていて取れませんでした… （写真を撮り忘れました）グラフィックボードはエアダスターで簡易的に掃除しました。すごい量のホコリが出てきました きれいになりました 補足 このグラフィックボードはブロワー型で、PCケース内に熱がこもりにくい設計になっています。ファンは数年単位で回転し続けているのですが、異音もせず回っています。大変丈夫です。 最近のグラフィックボードにはセミファンレス機能が搭載されており、低負荷時にはファンが停止します。しかし、このモデルにはその機能がないため、ファンはつねに回転し続けています。 おわりに 清掃前：サーマルスロットリングが発生清掃後：サーマルスロットリング解消定格のTDP 215Wまで性能を発揮できるようになりました。最大温度も88°C → 80°Cと改善しています。 機会があればグラフィックボードの分解清掃に再チャレンジしようと思います。
-
【雑談】 マツタケが栽培できない理由
会津ラボの阿部です。普段はバックエンドエンジニアをしています。今回はソフトウェアには全く関係のない、マツタケに関する雑談です。 出典: 森林総合研究所 九州支所／菌根の話 https://www.ffpri.affrc.go.jp/kys/business/tatuta/kinoko/kinkon.html はじめに 日本におけるマツタケの歴史は古く、縄文時代にはすでに食べられており、平安貴族はマツタケ狩りを楽しみ、江戸時代には大衆向けにマツタケの料理本が発行されていたようです。日本では高級な食用キノコとされる一方で、海外では不快な臭いとみなされて人気は今ひとつのようです。近年では国内市場に流通するほとんどが輸入品で占められ、国産品は貴重な存在です。海外では見向きもされないキノコですが日本では高級品ですので、まさに金のなる木ならぬ金のなるキノコですね。 ここからが本題です。他のキノコのように人口栽培できればみんな嬉しいところですが、マツタケは人口栽培が難しいキノコとされます。一体何が原因で難しいのでしょうか。 シイタケとの違い 同じ食材キノコであるシイタケとの違いを考えてみます。シイタケは枯れ木を養分にして成長するタイプのキノコ（木材腐朽菌）です。自然環境では枯れ木や倒木に根を張って成長します。木や草を腐らせて土に還す、よく知られる自然の分解者です。シイタケ栽培のホダ木はこれを人工的に再現したものですね。 一方でマツタケは樹木の根と一体化し、樹木に土中の水分やリン酸や窒素を渡す代わりに、樹木が光合成で作った養分をもらって成長するタイプのキノコ（菌根菌）です。樹木と共生関係にあり、樹木の成長を促す役割を持ちます。キノコの本体は木の根では届かない、土中の狭い隙間に入り込むことができます。 このようにキノコは、枯れ木に生えるキノコ（シイタケ）と地面に生えるキノコ（マツタケ）の２種類に大別されます。 マツタケは人口栽培が難しい このようにマツタケは樹木と共生関係にあり、生きた樹木がないと成長できません。これが、マツタケの人口栽培を難しくしています。 まず、栽培するスペース的な問題があります。マツタケと一緒に樹木も育てる必要がありますから、シイタケのようにホダ木を並べるわけにはいきません。また、樹木と一緒に成長するため成長速度もゆっくりです。樹木の光合成に依存するため、肥料をあげて直接マツタケの成長を促すことはできません。まるごと温室に入れて成長を加速させることは、あまり現実的ではないでしょう。さらに、キノコを作り出すためのトリガーなど、よくわかっていないことも多くあります。気温や降雨量が影響しているようですが、根本的にそれらをコントロールするのは難しいという問題があります。 マツタケの収穫量はその年によって大きく変動するそうですが、それは天候の影響を強く受けるからなんですね。 TIPS菌類のうち、いわゆる「キノコ」（子実体）を作るようなものがキノコと呼ばれ、それ以外のものはカビと呼ばれます。目に見えるキノコの部分は、繁殖のために胞子を散布するための器官です。つまり植物に例えれば花の部分になります。キノコの本体は枯れ木や地面の中にあるため、あまり目にすることはないでしょう。語源的には、「木+の+子」でキノコだそうです。わかりやすいですね。実際は植物と菌類で全くの別物ですが、シイタケもマツタケも樹木と密接な関係にあります。 おわりに 今回はキノコに関する雑談でした。次回は（あるとすれば）毒キノコに関する話題を取り上げたいと思います。
-
【C#】 System.Span とパフォーマンスの話
みなさんはじめまして、会津ラボの阿部です。普段はバックエンドエンジニアをしています。 今回は C# の啓蒙活動を行おうと思います。 はじめに C# もとい .NET Framework（v1.0、2002年1月） は .NET（v1.0、2016年6月） に名前が変わりました。よりアグレッシブに機能追加するよう舵切りがなされ、特にパフォーマンスが改善されています。今回は .NET のパフォーマンス改善の目玉である System.Span<T> に関する四方山話です。 Note四方山話（よもやまばなし）種々雑多な話。 世間話。 雑談。 よもの話。 C# は生産性を重視した言語であり、パフォーマンス改善の優先度はそれほど高くありませんでした。しかし C# コンパイラが C++ から C# で書かれるようになりパフォーマンスが重視されるようになります。つまり C# におけるパフォーマンス改善の流れは C# 開発チームの内需だったわけです。その他、昨今のクラウドコンピューティングの隆盛によってパフォーマンスがよくないと開発言語として選ばれにくいという側面もあります（最近だと AOT も盛んです）。 Span<T> とは、要は配列 Span<T> は連続したメモリを表します。読み取り専用の ReadOnlySpan<T> もセットで存在します。配列の使いにくかった部分を改善した型です。 後述のとおり Span<T> はパフォーマンス改善に繋がります。しかしながら、リストやシーケンスを使う場面では System.Collections.Generic.IEnumerable<T> を使ったほうがクエリ、並列処理、イテレーターなど自由度が高く、共変性もあります。結論として、Span<T> を使うのはライブラリ作成者が主体になりそうです。一方でライブラリ利用者は、Span<T> を意識せずパフォーマンス改善の恩恵を受けられます。 文字列を例に考える Span<T> によるパフォーマンス改善の例として、文字列を見ていきましょう。 C# の文字列型（string）は不変な参照型です。詳細は省きますが、かなり特殊な型で内部的には読み取り専用の文字配列（char[]）のようになっています。これは参照先で書き換えられることがないためコピーを渡す必要がないこと、コードを簡潔にできることが利点としてありますが、意図しないオブジェクトの生成が起こりやすい欠点もあります。 この問題は System.Text.StringBuilder を使うことで回避できます。…