刹那(せつな)の瞬き

Willkömmen! Ich heiße Setsuna. Haben Sie etwas Zeit für mich?

モニター用のスクリーンバーライトをつけたら目が楽になった

昨年末に、プリンストン スクリーンバーライトを購入して、一年経過しました。

夕暮れ時や薄暗く感じるけど照明をつけるまでではない時。
スクリーンバーライトでモニター前や手元を明るく照らすと、目がとても楽です。

一度経験してしまうと、もう手放せません。
毎日使用できないと困ります。

きっかけは部屋の模様替え

部屋の模様替えにより、室内照明の光がモニターの裏から当たるようになりました。
昼間はともかく、夕方以降は手元が薄暗くなります。

それまで気にした事はなかったのですが、手元が暗いとモニターの光を強く感じます。
目の疲労感も半端なく、モニターを見続けるのが辛い日もありました。

読書用の照明スタンドを使ってみましたが、手元を明るくするとモニターに光が差し込み、かえって見づらい状態になります。

とりあえずお試しで購入してみた

ネットで調べたら、モニター用ライトというジャンルがあり、目に良いとのこと。
しかし、私は利用した経験がないので、その有用性がわかりません。

モニターと同じ BenQ ScreenBar シリーズは初めて購入するには少々高額で、もし合わなかったら後悔しそうです。

一万円以下で評判の良さそうなものを探すと、プリンストン製のスクリーンバーライト (PMA-SCBAR) が目に留まりました。

値段も手頃だったので、失敗してもいいかな程度の気持ちで購入を決めました。

取り付けはモニターを選ぶ

購入して改めて気づいた点がいくつかあります。

  • モニターの前面に引っ掛けるツメが 8mm 程度
  • モニターの背面から押さえるバーがフラット
  • USB ケーブル給電のため、単独使用には別途アダプタ(5V/1A) が必要
  • USB ケーブルは 150 cm

まず、モニターの形状によって設置できない場合があります。
仕様書には、モニターベゼル幅 5 ~ 55mm との記載があります。

私は元々 BenQ PD2700Q に乗せるつもりで購入しました。
PD2700Q は前面に額縁状のベゼルがあり、背面もフラットなので問題ありません。

一方で EW2880U はベゼル部分がなく、背面はゆるく湾曲してます。
乗せられるものの安定感は今ひとつ。
引っ掛けるツメがモニターを傷つけそうで怖いです。

そもそもモニターアームなので、USB 給電ケーブルを給電元から十分に届かせる必要があり、現実的ではありません。

USB 電源アダプタでいつでも利用可

私は PC を利用していない時でも照明スタンド代りに手元を明るくしたいです。

説明書には「USB 給電 (5V) ※ 1A 以上出力可能な USB ポートへ接続してください」と記載されています。

手持ちの USB 電源アダプタでは、Apple USB 電源アダプタの 5W タイプが仕様を満たしてます。機種変更の度に余りがちなので、ちょうど良かったです。

実際に USB 給電元として使用したところ、特に問題ありません。

使用感は良好

気まぐれのお試しで購入したスクリーンバーライトですが使用感は良好です。
いつでもワンタッチで手元を明るくできます。

色々設定できますが、私は面倒なのであまり変更してません。
光度は白色 (3800K) で固定し、輝度は控えめで落ち着きました。

モヤモヤする事もある

輝度を控えめと書いたのは、私には明る過ぎたからです。
購入直後は明るさに驚き、輝度を最小以外に設定したくない思いでした。

ところが、使い始めて 3ヶ月程のこと。
突然バーライトの LED が激しく明滅するようになりました。
接触不良、ケーブル不良、アダプタ故障等を疑いましたが解決しません。

試しに設定変更で輝度を一段明るくしたところ、いきなり安定しました。
その後も最小設定のみ不具合を生じてたのですが、なぜか最近は問題ありません。
モヤモヤします。

モニター用ライトは良い買物だった

冒頭にも記述しましたが、本当に目が楽です。

私は眼精疲労や頭痛が減って助かってます。
正直なところ舐めてました。

あまりに快適で、私にとってモニター用ライトは必需品になりました。

そうなると高級品というか高いグレードの製品にも興味が湧きます。
次は BenQ ScreenBar モニターライトにするかもしれません。

BenQ EW2880Uにエルゴトロン LXデスクモニターアームを付けたら快適だった

昨年末に、エルゴトロン LX デスクモニターアームを購入して、一年経過しました。

現在は BenQ EW2880U に取り付けて、無印良品の木製折りたたみテーブルに固定し、快適な作業環境を確保できてます。

購入前の状態

以前はテーブルにBenQ EW2880U を単独で置いてました。

諸事情により部屋の模様替えが必要になり、機材レイアウトや配線も変更する事に。
その結果、BenQ PD2700Q も同じテーブルに置かないと収まりません。

実際に幅 120 cm x 奥行 70 cm のテーブルに両方置いてみると、少しハミ出ます。
PD2700Q を縦置きにすればピッタリなのですが、作業に支障をきたすので却下です。

なんとか配置を工夫してみたのですが、どうにも EW2880U の融通が効きません。
付属のモニタースタンドの足が V 字型で作業スペースを減らしてしまうのが難点です。

一方、PD2700Q は左右に角度調整・上下移動可。テーブルを塞ぐ範囲も少ないです。
PD2700Q 付属のモニタースタンドが如何に便利か良く分かりました。

エルゴトロン LX デスクモニターアームを購入

不便さを解消しつつ、作業スペースを確保するために、エルゴトロン LX デスクモニターアームを購入しました。

EW2880U 購入直後に候補として検討し、買うならコレと決めてました。
その最大の理由はアームがぶれない・下がってこないと評価されている点です。

確かに固い

実際に EW2880U に取り付けるとネットの情報通りアームが固めでした。

最初に動かそうとすると EW2880U のマウント部分が割れそうで心配になります。
そんな固さでしたが、テコの原理で少し押したらすんなり動き出しました。

一旦動いてしまえば、後は驚くほどスムーズに動作します。
私が購入した個体では一切調整不要でした。

テーブルの天板が心配

モニターアームをテーブルに固定する際、テーブルの天板の強度が心配です。

固定すると EW2880U (5.29kg) + LX (3.6kg) の重量が天板の一点に集中します。 
厚さ 1cm のラックに仮止めしたら、翌日には歪んでたので、無視はできません。

テーブルの天板はオーク材を加工したもので、厚さは 2.5cm です。
強度はそこそこありますが、念の為、エレコム製の取付補強プレート DPA-RP01BK を間に挟んで固定しました。

テーブルの足が心配

テーブル全体及び天板の対荷重は約 20kg です。

EW2880U と PD2700Q を合わせると約 16kg なので、小物類をまとめて約 1kg とすると、残りは約 3kg 程度の余裕しかありません。

そして、テーブルの足は金属製のパイプ状でボルト留めされてます。

配置した後に軽くゆすってみましたが、ぐらぐら揺れたりはしません。
PC 用の机ではないので、しばらく使用してどうなるか確認が必要です。

ちなみにテーブル自体の重量は約 16.5kg なので、部屋の床も心配だったりします。

一年経ちましたが快適です

エルゴトロン LX デスクモニターアームは噂に違わず安定してます。

EW2880U を固定位置からほぼ動かさずに過ごしましたが、少しもブレがありません。
隣に置いた PD2700Q との位置合わせをしてから、まったく変化してません。

テーブルの天板も歪みはなくフラットな状態です。
テーブルの足は一回ボルトの緩みを締め直したくらいで問題ありません。

....

不謹慎な話ですが、今年初めの地震で我が家も壁に亀裂が走り、配管が一本折れるくらいのダメージを受けました。

そんな揺れの中、テーブル上の小物や PD2700Q が動いても、EW2880U に取り付けたエルゴトロン LX デスクモニターアームは固定位置から微動だにしません。
テーブルごと揺れてるのに変化がないなんて、ちょっと感動しました。

不満といえばテーブルクロス

一年経って、最も困ったのはテーブルクロスを普通にかけられない事です。
テーブルに固定したので、当然ですが固定部が邪魔になります。

私はテーブルクロスをかけたい派なので、ビニール製のテーブルクロスに切れ目を入れて対応しました。

普通にテーブルクロスをかけるなら、別途マウント用のサイドテーブルを用意するか、壁固定にするかです。
ランチョンマット的なものを試してみたけど、掃除が面倒でやめました。

モニター購入の判断は正しかったか

今回は後からモニターアームを追加購入しました。
私の用途ではモニターを頻繁に動かす事はほぼないのにです。

結局 EW2880U を購入しましたが、PD2705U も候補の一つでした。
掛かった費用を合計すると、PD2705U より EW2880U の方が高くつきました。

PD シリーズにはない特長や良い点もあり、EW2880U の購入自体は後悔してません。
そして、モニターアームが優秀なのも間違いありません。

一方で、PD シリーズ付属のモニタースタンドの仕様であれば、角度も位置も問題なく、作業スペースも確保できます。
多少高額でも PD2705U にすれば良かったのかもしれません。

一概には言えませんが、今後の指針のひとつに加えたいと思います。

B450とRyzen 7 5700Xとメモリの妙な話

B450 マザーボードRyzen 7 5700X を載せた PC での話です。
手持ちのメモリは DDR4-3600 なのですが、3200MHz で動作させています。

CPU AMD Ryzen 7 5700X (Zen3)
M/B GIGABYTE B450 AORUS PRO WIFI (BIOS: F65 / AMD AGESA V2 1.2.0.B)
GPU NVIDIA GeForce GTX 1050 Ti
Mem G.Skill F4-3600C19D-16GSXWB (CL19-20-20-40) 8GB x 2 枚
A: DDR4_2, B: DDR4_1 に装着し、Dual Channel で動作
AMD CPU では CL20 。定格に合わせて 3200MHz 1.200V 駆動


さて、この PC の Linux 環境でビルド時間が 1 分を超えるプロジェクトがあります。

このプロジェクトでは 850 個以上のオブジェクトファイルが生成されます。
なので、ビルド時間が長いのは仕方ないです。

ですが、手持ちのメモリモジュールは OC メモリだけど DDR4-3600 です。
現在の動作クロックは 3200MHz ですが、3600MHz 運用を試したくなりました。

これで少しでもビルド時間を短縮できれば嬉しい限りです。

ところが 3200MHz の方が 3600MHz よりビルド時間が短い

そんな事を期待しつつ、3200MHz と 3600MHz でビルド時間を比較したところ、

■ 3200MHz (CL20-20-20-40) 1.20V 動作時
ninja  996.76s user 51.36s system 1359% cpu 1:17.10 total
ninja  1000.24s user 51.15s system 1379% cpu 1:16.22 total
ninja  994.60s user 51.09s system 1354% cpu 1:17.20 total
■ 3600MHz (CL20-20-20-40) 1.35V 動作時
ninja  1029.85s user 52.66s system 1358% cpu 1:19.70 total
ninja  1030.50s user 52.56s system 1383% cpu 1:18.30 total
ninja  1029.95s user 52.79s system 1385% cpu 1:18.15 total

残念ながら期待した結果になってません。

想定とは逆に 3200MHz 動作の方が数秒短い時間で完了しています。
しかも同じレイテンシ (CL20) なのにです。

メモリクロックを上げると同一時間内でのデータ転送量が増えるのに

私の想定では、メモリクロックを上げるとメモリ帯域幅が広くなり、結果として全体性能が向上するはずでした。

判断基準が崩れたので、まずはメモリ帯域幅を調査してみます。
Linux では STREAM でメモリ帯域幅を計測できるそうです。

(1) STREAM をビルド

公式サイトの "Source Code Directory" からソースコードを入手するのが正規ルートとは思いますが、私は GitHub から入手しました。

$ mkdir temp
$ cd temp
$ git clone https://github.com/jeffhammond/STREAM.git
$ cd STREAM
$ gcc -O2 -fopenmp stream.c -o stream_openmp

カレントディレクトリにstream_openmpが生成されます。

(2) STREAM の設定と実行

スレッド数を 96 に設定してからコマンドを実行します。

$ export OMP_NUM_THREADS=96
$ ./stream_openmp
 
(3) 実行結果

・3200MHz 動作

-------------------------------------------------------------
STREAM version $Revision: 5.10 $
-------------------------------------------------------------
This system uses 8 bytes per array element.
-------------------------------------------------------------
Array size = 10000000 (elements), Offset = 0 (elements)
Memory per array = 76.3 MiB (= 0.1 GiB).
Total memory required = 228.9 MiB (= 0.2 GiB).
Each kernel will be executed 10 times.
 The *best* time for each kernel (excluding the first iteration)
 will be used to compute the reported bandwidth.
-------------------------------------------------------------
Number of Threads requested = 96
Number of Threads counted = 96
-------------------------------------------------------------
Your clock granularity/precision appears to be 1 microseconds.
Each test below will take on the order of 8125 microseconds.
   (= 8125 clock ticks)
Increase the size of the arrays if this shows that
you are not getting at least 20 clock ticks per test.
-------------------------------------------------------------
WARNING -- The above is only a rough guideline.
For best results, please be sure you know the
precision of your system timer.
-------------------------------------------------------------
Function    Best Rate MB/s  Avg time     Min time     Max time
Copy:           16474.5     0.009888     0.009712     0.010094
Scale:          14672.5     0.011006     0.010905     0.011305
Add:            17845.3     0.013601     0.013449     0.013752
Triad:          16950.4     0.014359     0.014159     0.015236
-------------------------------------------------------------
Solution Validates: avg error less than 1.000000e-13 on all three arrays
-------------------------------------------------------------

・3600MHz 動作

-------------------------------------------------------------
STREAM version $Revision: 5.10 $
-------------------------------------------------------------
This system uses 8 bytes per array element.
-------------------------------------------------------------
Array size = 10000000 (elements), Offset = 0 (elements)
Memory per array = 76.3 MiB (= 0.1 GiB).
Total memory required = 228.9 MiB (= 0.2 GiB).
Each kernel will be executed 10 times.
 The *best* time for each kernel (excluding the first iteration)
 will be used to compute the reported bandwidth.
-------------------------------------------------------------
Number of Threads requested = 96
Number of Threads counted = 96
-------------------------------------------------------------
Your clock granularity/precision appears to be 1 microseconds.
Each test below will take on the order of 7064 microseconds.
   (= 7064 clock ticks)
Increase the size of the arrays if this shows that
you are not getting at least 20 clock ticks per test.
-------------------------------------------------------------
WARNING -- The above is only a rough guideline.
For best results, please be sure you know the
precision of your system timer.
-------------------------------------------------------------
Function    Best Rate MB/s  Avg time     Min time     Max time
Copy:           18774.9     0.008623     0.008522     0.008733
Scale:          16792.7     0.009668     0.009528     0.009716
Add:            19619.0     0.012304     0.012233     0.012494
Triad:          18706.5     0.012943     0.012830     0.013301
-------------------------------------------------------------
Solution Validates: avg error less than 1.000000e-13 on all three arrays
-------------------------------------------------------------

STREAM の実行結果から 3600MHz の方がメモリ帯域幅が広い事が確認できます。

これは期待通りの結果です。
実行する度に結果は変動しますが、傾向は同じでした。

他のベンチマークで計測してみる

メモリ帯域幅が広いのにビルド時間が遅くなる理由がわかりません。

そこで Linux でシステム全体のベンチマークを計測できるものを探したところ、PassMark Software 製のPerformanceTest Linuxを見つけました。

後述する内容は Ubuntu 24.04.1 LTS で実行した結果です。

(1) PerformanceTest Linux を取得・展開・実行

サイトから PerformanceTest Linux x86 64-bit をダウンロードして展開します。

$ wget https://www.passmark.com/downloads/PerformanceTest_Linux_x86-64.zip
$ unzip ./PerformanceTest_Linux_x86-64.zip 
Archive:  ./PerformanceTest_Linux_x86-64.zip
   creating: PerformanceTest/
  inflating: PerformanceTest/readme.txt  
  inflating: PerformanceTest/pt_linux_x64

展開後はpt_linux_x64を実行するだけです。

しかし、私の環境では共有ライブラリが不足しているのでエラーが発生します。

$ ./PerformanceTest/pt_linux_x64 
./PerformanceTest/pt_linux_x64: error while loading shared libraries: libncurses.so.5: cannot open shared object file: No such file or directory

Ubuntu 24.04.1 LTS では ncurses 系のバージョンは 6.4 で既にインストール済みです。

このままでは実行できないので、対象バージョンの共有ライブラリを手動で処理します。

$ wget http://archive.ubuntu.com/ubuntu/pool/universe/n/ncurses/libtinfo5_6.3-2_amd64.deb
$ sudo dpkg -i libtinfo5_6.3-2_amd64.deb
$ wget http://archive.ubuntu.com/ubuntu/pool/universe/n/ncurses/libncurses5_6.3-2_amd64.deb
$ sudo dpkg -i libncurses5_6.3-2_amd64.deb

共有ライブラリの依存関係により、libtinfo5, libncurses5 の順にインストールします。
/usr/lib/x86_64-linux-gnu/ にそれぞれ lib*.so.5.9 なライブラリが存在するはずです。

(2) 実行結果

・3200MHz 動作

                   PassMark PerformanceTest Linux (11.0.1002)


AMD Ryzen 7 5700X 8-Core Processor (x86_64)
8 cores @ 4661 MHz  |  15.5 GiB RAM
Number of Processes: 16  |  Test Iterations: 1  |  Test Duration: Medium
--------------------------------------------------------------------------------
CPU Mark:                          26223
  Integer Math                     94430 Million Operations/s
  Floating Point Math              51557 Million Operations/s
  Prime Numbers                    108 Million Primes/s
  Sorting                          34499 Thousand Strings/s
  Encryption                       22772 MB/s
  Compression                      321855 KB/s
  CPU Single Threaded              3435 Million Operations/s
  Physics                          1206 Frames/s
  Extended Instructions (SSE)      17835 Million Matrices/s

Memory Mark:                       3252
  Database Operations              7185 Thousand Operations/s
  Memory Read Cached               35227 MB/s
  Memory Read Uncached             24495 MB/s
  Memory Write                     15995 MB/s
  Available RAM                    13484 Megabytes
  Memory Latency                   45 Nanoseconds
  Memory Threaded                  43501 MB/s
--------------------------------------------------------------------------------

Results not submitted
Upload results to cpubenchmark.net? [Y/n]:

Use ESC or CTRL-C to exit
A: Run All Tests   C: Run CPU Tests   M: Run Memory Tests   U: Upload Test Resul

・3600MHz 動作

                   PassMark PerformanceTest Linux (11.0.1002)


AMD Ryzen 7 5700X 8-Core Processor (x86_64)
8 cores @ 4661 MHz  |  15.5 GiB RAM
Number of Processes: 16  |  Test Iterations: 1  |  Test Duration: Medium
--------------------------------------------------------------------------------
CPU Mark:                          26005
  Integer Math                     92589 Million Operations/s
  Floating Point Math              50726 Million Operations/s
  Prime Numbers                    116 Million Primes/s
  Sorting                          34921 Thousand Strings/s
  Encryption                       21970 MB/s
  Compression                      306954 KB/s
  CPU Single Threaded              3436 Million Operations/s
  Physics                          1303 Frames/s
  Extended Instructions (SSE)      17248 Million Matrices/s

Memory Mark:                       3451
  Database Operations              7666 Thousand Operations/s
  Memory Read Cached               35225 MB/s
  Memory Read Uncached             25905 MB/s
  Memory Write                     17867 MB/s
  Available RAM                    13493 Megabytes
  Memory Latency                   41 Nanoseconds
  Memory Threaded                  47419 MB/s
--------------------------------------------------------------------------------

Results not submitted
Upload results to cpubenchmark.net? [Y/n]:

Use ESC or CTRL-C to exit
A: Run All Tests   C: Run CPU Tests   M: Run Memory Tests   U: Upload Test Resul

実行結果によると、Memory Mark では 3600MHz の方が 3200MHz より高い数値ですが、CPU Mark では逆転してます。

何度実行しても傾向は変わりません。
僅かな差ですが CPU の処理性能が落ちてる事が確認できます。

結局、メモリ設定は 3200MHz に戻した

私の場合、Linux 環境でビルド時間を短縮できないなら本末転倒です。
いくらベンチマークテストで傾向を調べても、ビルドの実行結果がすべてです。

その後、ビルド時間を短縮できるように、BIOS 画面から

  • CPU Clock Control
  • CPU Clock Ratio
  • System Memory Multiplier
  • Standard Timing Control
  • Advanced Timing Control
  • DRAM Voltage

等の設定値を変更して、組み合わせを色々と試しましたが、結果は芳しくありません。
なので、3600MHz ではなく 3200MHz 設定に戻しました。

また、3200MHz でも CAS Latency 等を詰めてみたのですが、時間短縮は数 ms 程度だったので、無理はせず CL20-20-20-40 のままにしました。

私の用途では当初の設定値が適切だったみたいです。
というか、この程度だとあまり利点はないので、元の状態で妥協します。

根本的に何か間違った事をしてなければ良いのですが...

自分用メモ

・気になる点

  • FSB:DRAM は 1:16 (3200MHz), 3:54 (3600MHz) 
  • B450 の SATASSD/HDD を接続しているから?NVMeでは?
  • Zen3 世代の CPU なので X570, B550 チップセットでは?
  • もし APU だったら?
  • 別のメモリモジュールだったら?
  • 関係ないけど Windows では?

 等々

・現在の BIOS 設定

M.I.T.
Advanced Frequency Settings
CPU Clock Control Auto (既定値)
Host Clock Value の表示は 100.00MHz
CPU Ratio Mode All cores (既定値)
CPU Clock Ratio Auto (既定値)
CPU Frequency の表示は 3.40GHz
Advanced Frequency Settings - Advanced CPU Settings
SVM Mode Enabled
Advanced Memory Settings
Extream Memory Profile(X.M.P.) Profile1
DDR4-3600 19-20-20-40-60-1.35V
System Memory Multiplier 32.00
Memory Frequency(MHz) の表示は 3200MHz
Memory Timing Mode Auto (既定値)
Advanced Voltage Settings
Dynamic Vcore(DVID) Auto (既定値)
Dynamic VCORE SOC(DVID) Auto (既定値)
DRAM Voltage (CH A/B) 1.200V
BIOS
<UEFI> CSM Support Enabled (既定値)
Peripherals
AMD CPU fTPM Enabled (既定値)

 

・メモリの設定値

DDR4-3200 CL18-18-18-38-56-1T 1.2V 動作まで確認済み

暇ができたら DRAM Calculator for Ryzen 等を利用して、もう少し詰めてみる

B450 AORUS PRO WIFIでsensorsの出力結果のラベルを変更する

以前、Linux でハードウェアの温度を取得するにあたり、こんな記事を書きました。

先日 PC の CPU を換装したので、改めて sensors を実行したところ、今までと同様に期待通りの出力結果が得られてます。

sensors の出力結果のはてな

実はずっと気になってた事があります。

it87 ドライバをロードして sensors の出力結果を見ると、

$ sensors

....(ざっくり省略)....

k10temp-pci-00c3
Adapter: PCI adapter
Tctl:         +39.8°C  
Tccd1:        +38.5°C  

it8686-isa-0a40
Adapter: ISA adapter
in0:           960.00 mV (min =  +0.00 V, max =  +3.06 V)
in1:             2.02 V  (min =  +0.00 V, max =  +3.06 V)
in2:             2.00 V  (min =  +0.00 V, max =  +3.06 V)
in3:             2.02 V  (min =  +0.00 V, max =  +3.06 V)
in4:           996.00 mV (min =  +0.00 V, max =  +3.06 V)
in5:           900.00 mV (min =  +0.00 V, max =  +3.06 V)
in6:             1.36 V  (min =  +0.00 V, max =  +3.06 V)
3VSB:            3.26 V  (min =  +0.00 V, max =  +6.12 V)
Vbat:            3.05 V  
fan1:           475 RPM  (min =    0 RPM)
fan2:             0 RPM  (min =    0 RPM)
fan3:             0 RPM  (min =    0 RPM)
fan4:             0 RPM  (min =    0 RPM)
fan5:             0 RPM  (min =    0 RPM)
temp1:          +26.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
temp2:          +30.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
temp3:          +39.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = AMD AMDSI
temp4:          +29.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
temp5:          +36.0°C  (low  =  +0.0°C, high = -120.0°C)  sensor = thermistor
temp6:          +41.0°C  (low  =  +0.0°C, high = -120.0°C)  sensor = thermistor
intrusion0:    ALARM

センサーから取得した温度が temp1 〜 temp6 のように表現されていますが、この値が何を指すのかよくわかりません。

BIOS 画面での温度表現は

BIOS 画面の「 M.I.T. 」メニューから「 Smart Fan 5 」を選択すると、画面の右下に次のような 6 種類の温度が表示されます。

🌡 CPU 41.0℃ 🌡 System 1 27.0℃
🌡 Chipset 31.0℃ 🌡 PCIEX16 30.0℃
🌡 VRM MOS 34.0℃ 🌡 VSOC MOS 39.0℃

前述の temp1 〜 temp6 はこれらを指すと類推して、適度に負荷をかけつつ、sensors と BIOS 画面の値の変動を見てると、それなりに傾向が分かります。

BIOS 画面のセンサーと sensors の対応表

そして、私なりに導出した結果がこちらです。

CPU temp3 System 1 temp1
Chipset temp2 PCIEX16 temp4
VRM MOS temp5 VSOC MOS temp6

私の勝手な決めつけなので、誤ってるかもしれません。
何処かに正規の対応表が存在するなら、ぜひ教えて欲しいです。

sensors の出力結果のラベルを変更

この対応表が正しいとして、sensors から出力される temp1 〜 temp6 の表記を変更してみます。

エディタ類で/etc/sensors.d/Gigabyte-B450-AORUS-PRO-WIFIというファイルを用意し、次の内容を記述します。

chip "it8686-isa-0a40"
  label temp1 "System1 Temp"
  label temp2 "Chipset Temp"
  label temp3 "CPU Temp"
  label temp4 "PCIEX16 Temp"
  label temp5 "VRM MOS Temp"
  label temp6 "VSOC MOS Temp"

ここでは、it87 ドライバで認識される "it8686-isa-0a40" の出力結果の内、 temp1 〜 temp6 の各ラベルを文字列で指定しています。

そして、sensors を実行すると、

$ sensors

....(ざっくり省略)....

k10temp-pci-00c3
Adapter: PCI adapter
Tctl:         +47.6°C  
Tccd1:        +42.8°C  

it8686-isa-0a40
Adapter: ISA adapter
in0:           960.00 mV (min =  +0.00 V, max =  +3.06 V)
in1:             2.02 V  (min =  +0.00 V, max =  +3.06 V)
in2:             2.00 V  (min =  +0.00 V, max =  +3.06 V)
in3:             2.02 V  (min =  +0.00 V, max =  +3.06 V)
in4:           996.00 mV (min =  +0.00 V, max =  +3.06 V)
in5:           900.00 mV (min =  +0.00 V, max =  +3.06 V)
in6:             1.36 V  (min =  +0.00 V, max =  +3.06 V)
3VSB:            3.26 V  (min =  +0.00 V, max =  +6.12 V)
Vbat:            3.05 V  
fan1:           544 RPM  (min =    0 RPM)
fan2:             0 RPM  (min =    0 RPM)
fan3:             0 RPM  (min =    0 RPM)
fan4:             0 RPM  (min =    0 RPM)
fan5:             0 RPM  (min =    0 RPM)
System1 Temp:   +28.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
Chipset Temp:   +32.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
CPU Temp:       +49.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = AMD AMDSI
PCIEX16 Temp:   +31.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
VRM MOS Temp:   +39.0°C  (low  =  +0.0°C, high = -120.0°C)  sensor = thermistor
VSOC MOS Temp:  +45.0°C  (low  =  +0.0°C, high = -120.0°C)  sensor = thermistor
intrusion0:    ALARM

無事、ラベルの表記を変更する事ができました。

B450だけどRyzen 7 5700Xに換装して過ごす

先月下旬に Ryzen 7 5700X (Zen3) を購入しました。

既存 PC の CPU を Ryzen 5 2600X (Zen+) から換装するためです。

今更の Socket AM4 ですが、CPU 換装による既存環境の延命が目的です。
ついでに、ほんの少しだけ性能アップを期待しての購入です。

後述するのはその顛末です。

古い AMD 製 CPU は AGESA アップデートの対象外なのか?

今年 8 月、AMD 製 CPU のセキュリティ脆弱性 Sinkclose の存在が公開されました。

修正パッチの提供も開始されたのですが、古いモデルの CPU は対象外との事。
当初 AMD はソフトウェアサポート期間が終了した認識だったようです。

その後、デスクトップ向けでは Ryzen 3000 シリーズ以降が対象になりました。
私が使用してる Ryzen 5 2600X は、残念ながら修正パッチの対象外です。

....(事後の余談)

などと思ってたのですが、CPU 換装後 2024-10-30 にアナウンスが更新されました。
CVE-2023-31315ComboAM4PI 1.0.0.C (2024-10-17) で Pinnacle Ridge 等に対応してるそうです。

後は M/B メーカーから ComboV1 系の BIOS が提供されるかどうかでしよう。
私は既に BIOS を ComboV2 系にしているので、どちらにせよ CPU 換装を選択します。

現状に不満はないけど CPU 換装はアリかも

脆弱性について少し調べたところ、私の用途では緊急性を感じませんでした。
リスクが残るのは事実ですが、この度合いでは PC 環境の刷新まで考えられません。

仮に十数万円投資して Socket AM4 から Socket AM5 や Intel 系へ移行しても、今の私には過剰だと思います。

別件で記事にしましたが、私の用途では特に不満がないからです。

将来 AI を積極的に利用する機会が訪れたら、その時は CPU, NPU, GPU 等について総合的に見直したいところです。

....

本当に今更な Socket AM4 ですが、2024年11月時点でも Ryzen 5000 シリーズの新しい CPU が発売されるくらいなので、もうしばらく AMD のサポートは続きそうです。

Socket AM4 に固執するつもりはないのですが、少しの出費で PC 環境を維持できるのであれば、より長く使えるよう CPU 換装も良さそうです。

内臓 GPU 不要であれば Ryzen 7 5700X が良さそう

件の修正パッチは B450 AORUS PRO WIFI BIOS: F66d で対応済みです。

そして CPU 換装の予算ですが、基準を 25,000 円程度としました。
安いに越したことはないけど、数千円の差なら高くても性能が良い方を選択します。

換装を前提に、改めて私の用途や環境を吟味すると、ポイントはこんな感じです。

  • 常用する OS は Linux (KDE neon, Ubuntu, openSUSE 等 )
  • Windows はあまり利用しない
  • GeForce で構築済みの各 OS 環境を維持したいので、内臓 GPU 有無は問わない
  • 仮想マシンやコンテナ類は常時利用
  • 最も CPU 性能を必要とするのはコンパイルエンコード
  • 可能ならコア数 / スレッド数を増やしたい
  • 可能なら TDP が少ないものを選択したい
  • DDR4-3600 な O.C. メモリを所有しているので、DDR4-3200 運用もアリ
  • CPU クーラーは別途購入済みなので、有無は問わない
  • SSD/HDD は B450 の SATA ポート接続のみ
  • NVMe は利用していないので、PCIe 3.0/4.0 は問わない

これらを鑑みて調査を進めたところ、私の環境には Ryzen 7 5700X が良さそうです。

当初は Ryzen 5 2600X に合わせて PCIe 3.0 な Ryzen 5 5600G が候補でした。
換装ではなく、新規ですべてを一から構築するなら選択してたかもしれません。

今回は環境を維持しての換装なので、予算枠での性能向上に重点を置きました。

....

CPU サポートリストを確認したところ、Ryzen 7 5700X は BIOS: F62 で対応済みです。

  • Zen+ から Zen3 による処理能力の向上
  • コア数 / スレッド数は  6/12 (2600X) から 8/16 (5700X) に増加
  • TDPは 95W (2600X) から 65W (5700X) に減少
  • 実売価格は 24,000-25,000円付近で予算内 ※ 2024-10-20 時点

後は購入する・しないを含め、どうするかです。

急な販売価格の高騰、しかし Amazon だけ安い

その後、気が向いたらネットで CPU の価格を調べるようになりました。

積極的に購入するつもりはなかったのですが、為替レートの影響で価格改定が入るのは何度も経験しているので、調査は必要でしょう。

そんなある日。 夕方の時点での実売価格は 24,000-25,000 円付近でした。

その翌日。たまたまクレジットカードの更新があり、再登録ついで送料を確認しようと、5700X をカートに入れたところ、販売価格が約 30,000 円に跳ね上がってます。

慌てて利用してる販売サイトをいくつか確認したのですが、どこも同様です。
最も高額なところは 34,000 円以上の値がついてました。

....

それから数日後、Amazon.jp に AMD の限定販売品を見つけ、それを辿ると、何故か送料込みで 24,380 円と安い価格のままです。

安く購入できるラストチャンスかもしれないと思い、即座に購入を決めました。

※ 2024-11-14 時点の実売価格は 23,000-25,000 円付近で落ち着いてます。

....

今考えると自分でも焦りすぎな気がします。

しかし私には、このパターンで購入そのものを逃した、苦い経験があるのです。
今回は無事に必要なパーツを入手できたのでヨシ!と納得してます。

購入。直ちに換装

換装前に M/B の設定値を default に戻し、BIOS を F65 に更新します。

最新 BIOS のひとつ前ですが、Sinkclose 対策をどうするか決めかねてます。
必要なら F66d, 不要なら F66b だけど保留中です。

また、CPU を換装すると暗号化関連の構成が変更になります。

私はそれが嫌で暗号化関連は敢えて無効にしてます。
最近はデスクトップ PC でも暗号化を推奨してるけど、私的利用では暗号化までしたくないのが本音です。

....

CPU の換装作業は何度も経験してるので、特に問題ありません。

ただ、6 年も構成を変えてない PC なので、グリスの状態が少し気になります。
念の為、グリスが緩まる事を期待して、OS のアップデートや memtest 等で CPU 負荷をかけ、CPU 周りを温めてから作業しました。

換装後に電源を入れると、ブラックアウト状態のまま何度か再起動・シャットダウンする事になります。

BIOS 画面が起動したら暗号化関連を再設定して、設定値を元に戻します。
後は各 OS の起動確認をすれば作業完了です。 

CPU 換装後の所感

各 OS 環境は無事に動作してます。

正直なところ、体感速度はあまり変化してません。
CPU 換装と DDR4-3200 設定により処理性能は向上したはずですが、その程度です。

これは私の PC 構成による影響が大きく、換装前から承知してた事です。
元々、ボトルネックは B450 の SATA ポートに接続してる SSD なので、NVMe に移行すれば体感速度の違いを感じるかもしれません。

ただ、以前に HDD から SATA SSD への換装時、劇的な体感速度の向上を経験しており、その時の感動を超える事はなさそうです。

Windows 11 23H2 での話

Windows 10 から Windows 11 にアップグレードし、その後 23H2 まで更新してます。

気のせいかもしれませんが、その都度もっさり感が増してるように感じてました。
現在はそのもっさり感が少し減って、Windows 10 時代に戻った感じです。

少し気になった事といえば、Windows 11 23H2 のライセンスはそのままアクティブ状態だったのですが、Office 2019 の起動時に再度ライセンス認証が必要でした。

別にライセンス違反はしてないので問題はないのですが、気にはなります。

KDE Plasma 6 の Wayland セッションでの話

私の環境では X11 セッションとほぼ同様の CPU 負荷に落ち着きました。

換装前は CPU 負荷が 20-50% くらいありましたが、今は数%未満で推移してます。
もしかしたら、KDE Plasma 6.2.3 にアップデートした結果かもしれませんが、快適なのは良い事です。

その他

所有する PC の中で最もコンパイルが遅く、M1 Mac mini に完敗する環境でしたが、CPU 単体の換装でも幾分かマシになりました。

ベンチマークテストのように具体的な数値は示せません。

とあるプロジェクトのビルドに 1 分数十秒要していたものが、 1 分未満で完了する程度には改善されてます。
単純にコア数が増加した恩恵とは思いますが、より速く完了するのは助かります。

思いつきと焦りによる CPU 換装でしたが、結果にはそこそこ満足してます。

Windows11 23H2にKB5044380を適用したら、常時Windowsが起動して困るので対処してみた

私は PC に複数の SATA SSD を装着し、それぞれ異なる OS をインストールしてます。

先日 Windows 11 Version 23H2 の累積更新ブログラム KB5044380 を適用しました。
更新自体には特に問題はありません。

しかし更新後、常に Windows 11 が起動するようになりました。
BIOS で「 Boot の順序を変更」しても、Windows 11 を起動した後は BIOS の設定値が変更されます。

....

私は Windows を常用していないので、この状態はとても困ります。

普段使いは KDE neon ですが、現在は Btrfs 絡みで openSUSE Tumbleweed を起点にしてます。 

毎回 BIOS 起動するのは面倒なので、各種設定を確認してみました。

1. BIOS で Fast Boot を Disabled

当然ですが、今までも Fast Boot は Disabled にしてました。
確認したところ、Fast Boot は Disabled のままです。

ここまで勝手に変更されなくて良かったです。

2. WIndows 11 で高速スタートアップの無効化

私の環境は Windows 10 からアップグレードしたものです。

当時は「コントロール パネル」の電源管理から無効化してました。
しかし、コントロール パネルを起動したものの、設定項目が見当たりません。

....

色々と調べたところ、現在は「ターミナル(管理者)」からコマンド一発です。

PS C:\User\xxxxxxxx> powercfg /h off

これで、高速スタートアップは無効化できます。

3. BIOS で Boot Option Priorities を確認

改めて BIOS 画面から起動デバイスと優先順序を確認します。

最優先を openSUSE に設定し GRUB メニューから Windows 11 を一旦起動。

再起動とシャットダウンの後、それぞれ BIOS 画面で確認したところ、設定した優先順序はそのままでした。

これで元通りです。

あとがき

この件の調査の過程で知ったのですが、「Windows/Linuxデュアルブート環境が壊れる問題」もあるようです。

1本のデバイスに複数 OS はそれなりに便利です。
私も MBR 時代はそのような構成にしてました。

しかし、EFI Boot が主流になってから、私は 1 デバイス 1 OS にしてます。
私は Linux 環境が必要だし、GRUB は嫌じゃないので、Linux 環境を起点にしてます。
そのため Windows のブートマネージャは一切変更してません。

GRUB なしでも、一手間あるけど BIOS 画面で起動デバイスの変更は容易ですし。

....

そもそも 1 台の PC に複数の OS を必要とする人がどれだけ存在するかはわかりませんが、少なくとも私は必要としてます。

なので、セキュリティ強化の一環で 1 PC 1 OS とか制限される未来は嫌だなぁ。

KDE neonをUbuntu24.04.1ベースに更新後、Marble Mouseのスクロール設定を再確認

つい先日、KDE neon でも Ubuntu 24.04 LTS のポイントリリースに対応したアップグレードが提供されました。

私の環境は昨年10月付近の ISO イメージからクリーンインストールしたものです。
当時の KDE neon は Plasma 5 (Ubuntu 22.04 ベース) でした。
それからチマチマとアップデートを続けて現在に至ります。

正直なところ、OS のアップグレードにあまり良い印象はありません。
少なからず大小のトラブルを経験してるので、懸念はあります。

今回は過去の経験を踏まえ、事前調査を念入りに行いました。
その結果、問題ないと判断し、アップグレードしてみました。

Ubuntu 24.04.1 ベースへの移行はスムーズ

今回、アップグレード時にリポジトリに存在しないパッケージはすべて削除しました。
過去にリポジトリ絡みのゴミで混乱した事もありますが、今回はオールセーフ。

その後 Microsoftリポジトリのみ手動で再設定しましたが、余計だったかも。
KDE Plasma 6.2 での X11 / Wayland の各セッションも以前のように使えてます。

現状、特に問題ありません!
と、言いたい所ですが、Marble Mouse のスクロール設定に不具合が生じました。

X11 セッションの場合

アップグレード前は件の Marble Mouse で問題なくスクロールできてたのですが、右ボタン(小)が無効扱いになってます。

設定については、以前の記事のままです。

Kubuntuで確認しながら書いた記事ですが、KDE neon でも同様です。

....

調査したところ、KDE システム設定でも変更が必要でした。

これで Marble Mouse のスクロール機能が復活しました。

Wayland セッションの場合

Wayland セッションはアップグレード前と同様 Marble Mouse でスクロール可能です。

設定変更はありません。ちなみに設定は以前の記事のままです。

Input Device のイベント番号を調べて qdbus でパラメータ変更すれば OK のはず。

....

本件とは直接関係ないのですが、アップグレード時点で qdbus へのパスがありません。

私の環境では、qdbus 関連は/usr/lib/qt6/bin/に存在してます。
しかし、パスが通っていないため、軽率にコマンド実行できません。

所在は確認済みなので、そんなに困りはしないのですが...
クリーンインストールの場合だと状況が異なるかもしれません。

 

あとがき

元々、私の利用環境では Ubuntu 22.04 ベースのままでも特に不満はありません。
そろそろ Wayland に移行したいのは本音ですが、諸事情により今は X11 固定です。

LXD コンテナの件もあり、あまり環境をいじりたくなかったのですが...
なぜか突然、LXD コンテナを初期化する必要がありました。

そもそも「アップグレード可能」と都度表示されるインジケータの圧が強い!
そこで心が揺れてたのに「しない理由」を挫かれ...好奇心にも負けて...

結局はあっさりアップグレードしてしまいました。

しかしながら、後悔はしてません。
新しい環境は快適です。

....

実は私、普通の Ubuntu 22.04 から Ubuntu 24.04 へのアップグレードに失敗してます。

OS のアップグレード自体は問題なかったのです。

ところが、何も考えず NVIDIA Driver を強引に更新してしまいました。
その後、何をどうやってもVGA表示のままです。

Ubuntu 18.10 からアップグレードし続け、維持してきた環境。
愛着はありますが、今の私の知識ではどうやっても元に戻せません。
とても悔しいですが、諦めて削除しました。

....

そんな訳で、割とビクビクしつつアップグレードしたけど、移行はスムーズに完了。

NVIDIA Driver 関連も KDE Plasma 6 では問題なしでした。