2024年3月11日月曜日

久しぶりに参拝サイクリング

ブログでは去年11月以来ロードバイク絡みの話を書いておりませんが、去年9月下旬からサイクリングを再開し、10月・11月・12月と3ヶ月連続で「月間100kmオーバ」で走っておりました。

まぁ、それだけ回復してきた、ということでもありますが、落ちてしまった体力はそう簡単には戻ってきません。

毎回、20kmとか25kmとか走る程度、時間にして1.5hほど走ってるだけで「脚ダル〜い」「肩ダル〜い」「首しんど〜い」「尻痛ぇ〜」という体たらく。週に1度走る程度で「戻る」のを期待したらあきませんよね。

年明け以降は、1月5日に一度だけ走りましたがそれ以降は2ヶ月ほどご無沙汰し、3月に入ってようやく金山媛神社・金山彦神社に参拝サイクリングしてきました。少し斜度が緩くなったところではギア1枚上げて…なんてことをする気力体力は無く、登り始めから軽ぅ〜いギアを「ゆっくり漕いで」ヘコヘコ・ヨロヨロと登ってました。

急にとんでもなく元気になることはないので、まぁ、ぼちぼち楽しんでサイクリングすることにします。滝畑ダムまで行って帰ってこれるぐらいになったらイイな〜、なんて思いつつ。

2024年3月9日土曜日

空調設備をコントロール

BIOSには贅沢なほどたくさんの機能が備わっていて、古い時代しか知らない年寄りには「???」が消えない設定項目も多いんですが、それはさておき、CPUの温度などによりファン回転数を制御する機能がBIOSには搭載されています。

負荷の高い処理をする予定もあまり無いし、あったとしてもCPU温度が上限値で制限されてて自動的にクロックダウンするなり電圧を落とすなり安全側に倒れてくれるんでしょうから、ファンの動作をおとなしめに設定しておくことにしました。

で、本当ならBIOSでやるのではなく、OS上でfancontrolを使ってやりたかったのですが、BIOS側の自動FAN制御をDisableにする方法が無くて、BIOSでも制御がかかる・OS側からも制御してしまう、で競合して変な具合になってもイヤなので、BIOS側で対応するしかありませんでした。

そういう中でもfancontrolにも使いみちがあって、CPU負荷が高まりCPU温度が高くなってもFANを低回転に保つよう設定することで、「CPUクーラー(ヒートシンク)に熱がちゃんと伝搬してるのか」を確認することができます。

FAN回転が超ユルユルになるので、熱伝導がちゃんとできていればヒートシンクがほんのり温かくなってくるので「CPUクーラーをちゃんとセットアップできてるな」と確認できます。熱電対の温度計でヒートパイプ付け根辺りを測ってみたら40℃ぐらいに上がってたのを確認しました。

fancontrolが使えるようになったのも、前回記事で書いたnct6775ドライバを有効化したおかげで、とりあえず「やっといてよかったな」という感じです。何の値が表示されてるのかよく分からない項目が多くて、lm-sensorsのコンフィグで ignore を指定してみたんですが、残念ながら消えないんですよね…。

ということで、パソコン空調設備の調整も完了、と。

部屋の温度が高まる季節には、微調整が必要になるかもしれませんけどね。

 ★

ファン制御とは全く関係無いですが、今朝BIOSを最新版2.08に更新しました。

ASRock A620M Pro RSを買って真っ先に、当時ASRockウェブ上に掲載されていた2.08betaに更新したんですが、今月初旬にbetaが取れて正式版になったようです。なので、機能的には何も変わらんのですけどね。

BIOSの更新は、やり慣れないとギクっとすることやドキドキすることが多いです。最初の更新はCPUもメモリも使わない「M/Bと電源だけ」でやる方法でしたが、背面LEDでしか状態が分からず思ってた以上に時間がかかってドキドキしまくりでした。「BIOS飛ばしてしまうんちゃうか…」と。

2度めの今回はBIOS中にある更新機能を使ってやりましたが、これも、開始してスグにプツン!とリブートかかりやがって「えーっ!」て声を上げてしまいました。リブートの後にちゃんと更新処理が始まるんですが、そういうモンだとちゃんと理解してやらんと、心臓に悪いっす。


2024年3月3日日曜日

各種センサー値のモニタリング

lm-sensors & Psensorという組み合わせですが、Ubuntu 23.10のデフォルトではファン回転数や各種電圧などが取得できません。

で、どうにかする方法は無いのか…と少し調べてみたところ、ASRock B650M Pro RSという「似たようなモデル名」の製品でnct6775ドライバを使う情報が見つかって、モノは試しで書いてある通りにやってみた結果が左の図の通り。Psensor上にはファン回転数は出てきましたが残念ながら電圧は出てきません。sensorsコマンドでは電圧値も取得できているようです。

当方システムの構成としてはファンはCPUファンとケース背面ファンの2つのみ装着。でfan1とfan2でそれらしき値が取得できていて、どっちがどっちなのかよく分からないんですが(涙)、まぁ、どっちかがそっちなんだろうな、とそんな感じです。(なんやそれ)

電圧値は、おそらくin0がCPUのコア電圧のように思えます。負荷の無い時は0.7V程度、CPU負荷をかけると1.35Vにリニアに上がりますので「コレかな」と思いました。その他のin2〜in14がそれぞれ何の値なのかさっぱり分かりませんw

肝心のCPU温度ですけど、値を見て一喜一憂するのをやめました。stressコマンドで100%のCPU負荷をかけると一気に85℃まで上がります。計測値としては86℃とか87℃も見えることがありますが、まぁそういう値で一定します。で、なぜ一定するか?というと、BIOSで制限されていました。BIOSの設定はデフォルトで「auto」なんですが、これが85℃制限のようです。設定値を75にすると、ほぼきっかりその値でサチります。

ということは、安全マージンを持ってautoに設定され85℃で制限されてるんでしょうから、その温度で稼働しても問題は無いはず。という理解です。事実、85℃で稼働中も、CPUクロックは定格を超える5100MHzを示すことがあります。つまり、サーマルスロットリングなんて起こってない、と。

試しに、Pixel 4a向けのLineageOS 21.0をビルドしてみましたが、ソースのダウンロードも含めトータル3hほど高負荷状態を続けましたが、なぁ〜んも問題ありません。

仕様的な制限値は95℃らしいですし、コア内部が85℃になっても問題無いんでしょう。

と理解することにしました。ということで、「センサー値モニタごっこ」はこれでおしまい。

「念の為」というと変ですが、リテールクーラのまま通年運用する気になれなかったので、サイズの虎徹 Mark3 にリプレースしました。接触面には長年手持ち在庫していた信越のフェイズチェンジシートを使いました。安心安定の長期間性能維持。信越のG751グリスも少量ですが在庫してるんですが、「年イチでグリス塗替え」なんてやってられないので。

2024年2月20日火曜日

AMD CPUの温度管理で悶々

負荷の高い処理なんてする予定が無いマシンですが、それでも「何かの拍子に…」ということもありえるので、現状実態として「どの程度のモノなのか」を知っておく必要があるワケです。

ということで、技術評論社の記事にあるスクリプトを使わせていただいて実験してみたのが左の図。

パっと見とくに問題無いように見える(事実この状態は問題無い)んですが、気になるのは、Tctl, Tccdが85℃でサチってるように見えること。何らかの機構で制御されてこうなってるのか、ベンチマーク負荷的に「この程度だった」のか。Intel製CPUであればthermaldというデーモンが動的にCPU動作(クロック)を制御するようなのですが、当該デーモンは「AMD CPUをサポートせず」ということなので、じゃぁこのマシンではいったいどうなってるんじゃい!と…。

スクリプトのベンチマークとは別に stress -c 12 で20分間ほど様子を見てみましたが、モニタできた温度はスクリプトの時と全く変わらず。全CPUが100%でTctl, Tccdとも85℃前後で一定、という状態。CPUクロックは、stress実行直後は4.7GHzでしたがすぐに4.6GHz台に落ちましたが一定しておりました。

室温21℃の環境での実験でしたが、室温が上がればそれに応じてモニタできる温度も上がるのか、そうじゃなくて85℃前後で一定するのか。また、CPU温度に対して動作クロックが自動制御されるのかされないのか。この点がまったく分かりません。(調べ方が下手なのか…)

現状は、CPUクーラは7600付属のリテールクーラを使用、ケースファンは前面は無しで背面にThermalrightのTL-C12(500rpm〜1500rpm)を使用、という簡素な排熱処理系です。気にしてるのは、このままで真夏もイケるのかどうか、冷却強化が必要なのかどうか、ということで。

悩んでるぐらいなら、Scythe虎徹Mark3ぐらい付けとくのがよいのかもしれませんが…

最初Ubuntu Desktop 23.10を導入しておりましたが、少しジタバタしてみたくなって、Linux MINT 21.3を試してみたり、Ubuntu Desktop 23.10 Cinnamonを試してみたり…。結局、Ubuntu Desktop 23.10 Cinnamonに落ち着きました。デフォルトでインストールされていたFirefoxが「画面、砂嵐状態」でしたが、アンインストールしてMozillaサイトから手動でインストールし直したら解決(回避?)。

とりあえずこの状態で当面しばらくは過ごす予定。「当面しばらく」の意味は「24.04 Cinnamonの正式リリースまで」ということ。

2024年2月17日土曜日

LineageOS 21へ(Pixel 4a)

まったく予想していませんでしたが、有志の方々の尽力により Pixel 4a にもAndroid14ベースのLineageOS 21がリリースされました。

一時期は PixelBuilds を使ったりしていましたが、開発の状況やユーザコミュニケーションの現場を見て「こりゃマズいっぽいな」と感じて、LineageOS 20に入れ替えておりました。

ので、LineageOS 20(20240208build)+Magisk(v27.0)という環境からLineageOS 21+Magisk(v27.0)への移行となりました。

事前にLineageOS 21のboot.imgにMagiskでパッチを当てておき、adb reboot sideloadしてからadb sideloadでLineageOS 21を導入、さらにreboot to bootloaderして再びsideloadにしてからadb sideloadでMindGAPPSを導入、その後もう一度reboot bootloaderしてから、fastboot flash boot で最初にパッチを適用しておいたboot.imgを(Active Slotに)導入。で、reboot to systemで、いじょ終了。(Lineage Wikiに書いてある通りのやり方に従っただけの話)

実際には自分のミスでちょっとトラブってしまいまして、元の環境にA14非サポートのPixel Launcher Extendedを入れてたのを忘れて、そのまま上記手順でLineage21を導入してしまいまして、ブートはするもののロック解除するとランチャーがcrashしてホーム画面を表示できない状態に。やむなく、adb install で適当なランチャーアプリを入れて(今回は手元にあったLauncher14 Dev版を使った)、画面スワイプからの設定でデフォルトホームアプリをLauncher14に変更してホーム画面を表示できるようにしまして、ようやくPixel Launcher Extendedをアンインストールすることができて、問題解消できました。

今はLauncher14もアンインストールして、LineageOS 21標準の Trebuchet を使っています。

こちらにはLineageOS 21での改善点などがたくさん説明されていますが、まだ全部を読みきれていません。とりあえず、現状では、何1つ問題なく普通に安心して使える状態にあります。

素晴らしい出来具合だと思います。