桐材にワトコオイルのナチュラル色は合わない
近頃の毎週末は棚づくりに勤しんでいる。サボり期間を経つつ1ヵ月ほどかけて、ようやく塗装までこぎつけた。
材料の桐の調湿性を損なわないよう(効果はほとんどないと思うけど気持ちの問題)、塗料はワトコオイルのナチュラルにしてみたんだけど、これがまぁ失敗かなと。期待とは裏腹にだいぶ黄色い仕上がりとなってしまった。
言わずもがな、上が塗装後で下が塗装前。塗装後の方は、桐の白く淡い感じが完全に消えパイン材みたいになってしまった。加えて、見にくいけど塗った方の右上、シブの部分(桐材特有の紫っぽく変色した部分)が茶色っぽく強調されて、大変残念な感じに……。
古びた感じを出したい人にはいいかもしれないけど、個人的には桐の風合いが台無しというほかない。桐を含め白っぽい木にはホワイトの方が合うと思われる。どこぞで「ホワイトは白色をそのままコーティングしたような仕上がり」と見てナチュラルにしたんだけど、結果的に選択ミスだった。
ウェット研磨と乾燥を経て、少しでも落ち着いてくれることを祈るばかりですよ。
初めてワトコオイルを使ってみたけど、だいぶニオイが独特。オイル系にしてはニオイ控えめって事らしいけど、とても室内で濡れるようなレベルではない。ドクダミとミントと灯油を混ぜたような、うんにゃりとした感じ。これならシンナーのガツンと臭い方がマシだなー(個人の感想です。)
Linux 5.7でintel_pstateのHWPの挙動が変わっていた
自鯖のProxmox VEを6から7に上げたら、アイドル時の消費電力が上がったような気がする。ハードウェア構成が少し変わってたりもするので何とも言えないところだが、IPMIで見る限り増えているのは確か。
あれこれ試してみたところCPUのスケーリングガバナーの挙動が変わっていた。そして、そもそもCPUドライバとしてintel_pstateではなくintel_cpufreqが使われていた。
# cpupower frequency-info
analyzing CPU 0:
driver: intel_cpufreq ★これ
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 20.0 us
hardware limits: 1.20 GHz - 3.30 GHz
available cpufreq governors: conservative ondemand userspace powersave performance schedutil
current policy: frequency should be within 1.20 GHz and 3.30 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency: Unable to call hardware
current CPU frequency: 1.20 GHz (asserted by call to kernel)
boost state support:
Supported: yes
Active: yes
同じ環境でPVE 6の時はintel_pstateが使われていたハズなんだけどなぁ。dmesgを見ると、intel_pstateが採用されている雰囲気だが、“HWP not enabled”の一文も気になるところ。
# dmesg | grep intel_pstate [ 2.020574] intel_pstate: HWP not enabled [ 2.020580] intel_pstate: Intel P-state driver initializing
答えはArchiWikiとintel_pstateのドキュメントに書いてあった。HWP (Hardware P-States)が使えないCPUではintel_pstateはPassive Modeとして動作し、ドライバとしてintel_cpufreqが使われるとのこと。お前かー!!
Linuxカーネルバージョン5.81)でのintel_pstateの改修により、この挙動に変わったらしい。実際、v5.7とv5.8のソースを見比べると、確かにそのような変更が加えられている。
話はこれで終わらずv5.9において、EPP (Energy Performance Preference)を持たないCPUをHWP制御から除外するコードがわざわざ追加されている。HWPはSkylakeからの実装とされているが、実際はBroadwell-EPで初期実装が行われているらしく、現に前述のv5.7コードではHWPを使うようになっている。
自鯖のCPUはまさにBroadwell-EPなXeonなので、見事に該当しているというワケだった。
強制的にアクティブモードにすることもできそうだが、どっちがいいんだろうねぇ?更にHWPM (Hardware Power Management)を使って、完全にハードウェア任せにするという選択肢もあるし悩ましいところ。
(2022-02-21 追記)
うちのマシンの場合アイドル時の消費電力は、やはりアクティブモードの方が気持ち低いようだ。
アクティブモードとパッシブモードの切り替えは/sys/devices/system/cpu/intel_pstate/statusに、それぞれactiveとpassiveを書き込むことで可能。切り替えた場合、スケーリングガバナーの変更もお忘れなく。
# cpupower frequency-info
analyzing CPU 0:
driver: intel_cpufreq
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 20.0 us
hardware limits: 1.20 GHz - 3.30 GHz
available cpufreq governors: conservative ondemand userspace powersave performance schedutil
current policy: frequency should be within 1.20 GHz and 3.30 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency: Unable to call hardware
current CPU frequency: 1.30 GHz (asserted by call to kernel)
boost state support:
Supported: yes
Active: yes
# echo active > /sys/devices/system/cpu/intel_pstate/status
# cpupower frequency-info
analyzing CPU 0:
driver: intel_pstate
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: Cannot determine or is not supported.
hardware limits: 1.20 GHz - 3.30 GHz
available cpufreq governors: performance powersave
current policy: frequency should be within 1.20 GHz and 3.30 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency: Unable to call hardware
current CPU frequency: 1.20 GHz (asserted by call to kernel)
boost state support:
Supported: yes
Active: yes
参考サイト
2022年、クソゲ〜製作所は「のふ処」に変わります(ました)
謹啓 初春のみぎり、いよいよご壮健の由、大慶に存じ上げます。
さて、日頃ご愛顧賜っております弊サイトは、2022年元日を以てクソゲ〜製作所から「のふ処」(のふどころ)に改名することとなりました。併せてドメインもnofu.jpに変わります。中身、コンテンツ、運営方針については従前通りで変更はありません。
要はただのサイト名とドメイン名の変更ですな。理由は以下の通り。
- SEO、検索性の問題
- ドメインが汚れてきた
- 地域性の明確化とドメイン名の短縮
decomo.infoは自分の名字と某大手携帯キャリアをもじって付けたものだけど、今となってはSEO的に非常に不利となっている。decomoで検索しても、あっちがサジェストされちゃうんだもの…大企業だしそれこそ重要なインフラを担ってらっしゃるので当然なんですけどね。 「クソゲ〜製作所」という名前も同様で、長音符がわりの「〜」は検索エンジンと相性が悪いっぽい。意味のある単語として認識されてないような挙動。波ダッシュ問題も影響してる気がして、非常によろしくない。
この名前は、ゲームプログラマを夢見た高校生の時代に「クソゲ〜製作所というブランドで面白いゲームを作ったら楽しいじゃん」という安直さと、クソゲーは作らないという少しの矜持を込めて付けたものだ。
それから幾年、曲がりなりにも夢は叶い、誰もが知る某有名タイトルなんかにも携わることができたが、ついぞ自分でゲームを作ることはなかった。実のところゲーム業界を離れて既に4年が経つし、ゲームという看板の降ろしどきかなと。
とはいうものの、「のふ処」の“のふ”はクソゲ〜のクを「ク→ノフ→のふ」と変化させ、“処”は製作所の「所」から来ているので全く無関係というわけではない。よりストレートな案として、当初はクソ所(くそじょ/くそどころ)もあったが、いろんな意味で直球過ぎてボツにした。個人的には嫌いではないけど、流石にメールアドレスとして公衆送信するのは憚られるのでw
メールアドレスの点では、decomo.infoだと冒頭の有名企業の兼ね合いでバッタもの感が強いし、20年も使ってると情報漏洩やら何やらで汚れて来るんですわ。そうなんですよ、decomo.infoは2002年3月27日に取得してるんで、今年で20年なんですよね。ちょっとビックリですよね。
そんなわけで丁度いい節目でもあるので、4文字と短く、日本発信ってのが明確で、字面と語感が何となく良いnofu.jpに移行する。
これ自体も2018年頃から考えていたもので、実際ドメインはその時に取得済み。移行作業は遅々と進まず、むしろ面倒で進める気もなかったのが実情だが、この正月休みでやっちゃおうと、ふと思い立ったが吉日ってなもんで。ついでにページのスタイルも昨今のレスポンシブな感じに。
本年もよろしくお願いいたします。
1.5PB書き込まれたPM9A3がPS5で使えなかった
PCIe 4.0なNVMe SSD、Samsung PM9A3 1.92TB (MZ1L21T9HCLS-00A07)が某所で2万円ちょいで売られていた。読み書き量が1520465GB≒1.5ペタバイトという代物で、相当にアレなブツではあるものの、 2TBのPCIe Gen4のNVMe SSDとしてはかなりの安値。PM9A3はエンタープライズ向けのSSDで1DWPDで5年の耐久性が謳われており、換算すると3504TBWとなる。仕様上の寿命は半分以上残っていることになるし、PS5用にちょうどいいんじゃね?ってことで買っちゃった。
お決まりのS.M.A.R.T.情報とベンチマーク結果。
読み書き量のわりに起動回数と時間が極端に少ない。耐久検査に使われたブツの流○品とか?1.5PBで残寿命88%ってことは、理論上は12.5PB書き込めることになる。
ベンチはPCIe 3.0接続であることに注意。うちにはまだPCIe 4.0なPCは無いのだ。
なお、ベンチ中はS.M.A.R.T.読みで80℃近くまで上がることを確認。それなりに冷却に気を使った方が良さそう。
で、肝心のPS5はというと、使えませんでした\(^o^)/
電源を入れると画面は真っ暗のままで、光学ドライブがガチャガチャ鳴る→鎮まる→鳴る→鎮まる…という状態を延々と繰り返す。状況的に途中でリセットがかかって再起動を繰り返してるような感じ。
別のPCIe 3.0なSSDで試すと「拡張スロットに装着されたM.2 SSDは使用できません。」の画面がちゃんと出たので、PS5本体は正常、何らかの理由でPM9A3が使えないっぽい。残念賞。
この微妙なPM9A3の処遇はどうしようかな…。
(2022-02-21 追記)
PS5で使えないのは、PS5のM.2スロットの電流供給能力の問題っぽい?下表は各SSDの電流値をまとめたもの。値は手元の現物SSDやネット上の画像から拾った。
| SSD | 電圧/電流 | 使用可否 | 備考 |
|---|---|---|---|
| PM9A3 1.92TB | 3.3V / 4.3A | × | 起動せず |
| PM9A1 2TB | 3.3V / 2.8A | ○ | 使えてるっぽい |
| 980 PRO 2TB | 3.3V / 2.9A | ○ | |
| FireCuda 530 4TB | 3.3V / 3.0A | ○ | |
| FireCuda 530 2TB | 3.3V / 2.9A | ○ | |
| PG4VNZ 2TB | ? | ○ | |
| PG3VNF 1TB | ? | ○ | |
| SN700 250GB | 3.3V / 2.8A | △ | PCIe 3.0なので使えないが起動はする |
こうしてみると、PM9A3が頭一つ飛びぬけているのが分かる。
M.2規格上の定義は探し出せなかったが、何となく最大電力は10W、3.3Vで3Aあたりが上限っぽいように見える。PM9A3に電力制限かければ動くかもしれないけど、突入電流の問題のような気もする。ごついコンデンサ7個(刻印見る限り47μF?)を除去すればワンチャンあるかも?知らんけど。
SupermicroマザボのファンをIPMIで制御する
Supermicroのマザーボードでファンの回転数をIPMI経由で制御するには、以下のコマンドを投げつければよい。
# 制御モードをFullにする ipmitool raw 0x30 0x45 0x01 0x01 # "system"ゾーンの回転数を37.5%にする ipmitool raw 0x30 0x70 0x66 0x01 0x00 0x24 # "peripheral"ゾーンの回転数を25%にする ipmitool raw 0x30 0x70 0x66 0x01 0x01 0x16
まず、ファンの制御モードを“Full”にする必要がある。他のモード(Optimalとか)だと、その設定の方が優先されるとのこと。その後、ゾーン毎に回転数を設定してやる。
2~3つ目のipmitoolで送っているバイト列のうち、最後がファンのデューティー比、後ろから2番目がゾーン番号を表す。ゾーンのsystemとperipheralは、マザボのFAN用コネクタFan1系列とFanA系列に対応していると思われるが確認したわけではないので間違ってるかも。
デューティー比は0x00~0x64の64ステップとされている。でも、16進数なんだから0~100なんじゃないの?という気が…ま、ともかく0x00が最小で0x64がフル回転だそうなので、こまけぇこたぁいいんだよ!
実際のところ、Optimalで割とイイ感じに制御してくれるんだけど、ファンによってはデューティー比低すぎて止まっちゃうことがあるんですよね。で、ファン停止エラーが検出される→フル運転→エラーが止まる→デューティー比下がる→ファンが止まる→…の無限ループになるという。
この場合ipmitool sensor threshで最低回転数のスレッショルドを調整するのが定石。うちでは設定値が悪いのか、上手く動いた試しがない。
ファン制御やスレッショルドを弄ってにっちもさっちも行かなくなったら、ipmitool mc reset coldでBMCをリセットしてやればおk。
参考サイト
- ファン制御
- スレッショルド変更







