ToDo:
先日、Antec P5に導入したNoctua NL-LC1-24の静音性と冷却性能のバランスが非常によかったので、MASTERBOX CM695で運用していたCooler Master MasterLiquid 360 Atmos II VRM FanをNoctua NL-LC1-36 + NL-ACF1に換装してみた
MasterLiquid 360 Atomos II比較でラジエータが5mm長いので 組み付けクリアランスはかなりギリギリだが、5インチベイ・リア排気ファイン(最下方設置)と共存して組み付け可能
配線に関しては、ラジエーター側での配線集約が無いので、接続順序等を考慮する必要が無いので楽というか普通
ファン回転数の最適化前の全開設定時の計測では、Ryzen 7950X PBO 85℃設定にてCooler Master MasterLiquid 360 Atmos II VRM Fan(同全開設定)を2.3%上回るスコアを叩きだし、アイドル時の最低温度も若干下がる模様
組み付け作業に合わせて、5インチベイの有無でファン全開設定時のベンチマークスコアを比較したが 0.4%の低下に止まるので、ファン1個分弱の領域を被う光学ドライブの影響は実用上問題ないレベルの模様
今回のNL-LC1-36は40dB切り運用(部屋の暗雑音38dB)でパワーを絞り出す想定での導入ですが、値段差考えると性能・静音性の極限を狙うので無ければ普通にMasterLiquidがおすすめです
暫く前に、16-CURRENTへnet/aquantia-atlantic-kmodのaq driverがマージされていたが、15-STABLEにもMFCされた模様
もっとも、このaq driverは現行世代のAQC113Cをサポートしてない＆ベンチマークした範囲だとTCP 1ストリームの割り込み密度だと10Gbpsに届き辛いので、新規調達ならRTL8127カードをnet/realtek-re-kmod driverで使うのがおすすめ (16-CURRENTだとnet/realtek-rge-kmod相等の rgeドライバがマージされたいたはず)
注意点としては
www/firefox-esrがビルド出来ないで報告したstable/15でビルド出来ない140.x系列のwww/firefox-esrだが、153.x系列に更新された
以前導入したRTL8127カードLGY-PCIE-MG3であるが、なんか動作が変…
同カードで動かしているWindows11が最近突然再起動するので様子を見ていたのだが、 本日Windows11の突然再起動してからFreeBSD側でnet/realtek-re-kmodで認識するが まともにDHCPが取れない状態が発生。
同ドライバーでマザーボード上のRTL8126だと問題なく動くので、 RTL8127カードの不良の模様…半年で壊れた？
現時点では永続的な故障には見えない
対策するとしても、取り付けスロットが窒息ぎみなので冷却不足を疑ってファンを増設するか、 製品不良を疑って予備品を確保するあたりか…
以前おかしくなった10GbE NICとしては、Intel X550-T2で一時的な通信エラーが発生し、 そのうち再起動しないと治らなくなり、最後は2portのうち使っていたポートが不通になった事例があるので 最新世代の2W級チップでも窒息ぎみの配置だと油断できない？
玄人志向のRTL8127カードに交換＆Noctua 60mmファン増設後は1週間程度連続に安定稼働している (追記 2026-07-27)
Noctua NL-LC1-24・NL-ACF1 vs ARCTIC Liquid Freezer III Pro 240の比較
Liquid Freezer III Pro比でRadiatorが薄くなっているにも関わらず、同等の冷却性能の模様
Liquid Freezer III Pro 240 (全開設定)とほぼ同じ性能で、雑音レベル-4.4dBが得られた
Liquid Freezer III Pro 240の40dB設定だと、Lap-Timeは670sec↑なので、騒音辺りの冷却効率はだいぶ上がった模様
Noctua公式の互換資料に在る通り NL-LC1-24はAntec P5で運用可能だが、Radiatorの冷却水ヘッダーを上にして設置する必要あり
これは、冷却水ヘッダー側と反対側の寸法に非対称性があるため(一方、Liquid Freezer III Proなどはほぼ対称)
おそらく、幅が同じNL-LC1-36にも同じような非対称性があるはずなので、360mm Radiatorを天板設置かつ5inchベイ使用する場合、 ケースの奥行きに注意が必要と思われる (最悪、リア排気ファンの設置を諦める必要が出てくる)
ibus 1.5.34不具合の件だが、1.5.34で問題なくktermに入力できる環境がある…何故 Orz
ibus 1.5.34 + ktermが動かない環境にXIMまわりの問題があるっぽぃのだが、ibus 1.5.34 + ktermが動いている環境もあるので謎が深まった
build環境の問題それとも依存ライブラリの更新失敗か？
パッケージを運搬して検証するば、build環境依存 or 実行環境依存の区別は出来そう
影響を見えるのがktermのみなので、EUC-JP localeでXIMを初期化するkterm固有のエンコーディングがらみかなぁ？
過去のXIM関連のトラブルは…
次の作業は、コアコンポーネントの差分を確認して、コンポーネント単位で巻き戻して動作検証か…
stable/15上でwww/firefox-esrのビルドが失敗する
warning: struct `ResultIter` is never constructed
--> /usr/obj/usr/ports/www/firefox-esr/work/firefox-140.12.0/third_party/rust/askama_derive/src/input.rs:611:8
|
611 | struct ResultIter<I, E>(Result<I, Option<E>>);
| ^^^^^^^^^^
|
= note: `#[warn(dead_code)]` (part of `#[warn(unused)]`) on by default
warning: `futures-executor` (lib) generated 1 warning
warning: `cssparser` (lib) generated 1 warning
warning: `askama_derive` (lib) generated 1 warning
gmake[3]: *** [/usr/obj/usr/ports/www/firefox-esr/work/firefox-140.12.0/config/makefiles/rust.mk:528: force-cargo-library-build] Error 101
gmake[3]: Leaving directory '/usr/obj/usr/ports/www/firefox-esr/work/.build/toolkit/library/rust'
gmake[2]: *** [/usr/obj/usr/ports/www/firefox-esr/work/firefox-140.12.0/config/recurse.mk:72: toolkit/library/rust/target-objects] Error 2
gmake[2]: Leaving directory '/usr/obj/usr/ports/www/firefox-esr/work/.build'
gmake[1]: *** [/usr/obj/usr/ports/www/firefox-esr/work/firefox-140.12.0/config/recurse.mk:34: compile] Error 2
gmake[1]: Leaving directory '/usr/obj/usr/ports/www/firefox-esr/work/.build'
gmake: *** [/usr/obj/usr/ports/www/firefox-esr/work/firefox-140.12.0/config/rules.mk:359: all] Error 2
*** Error code 1
Stop.
make[1]: stopped making "/usr/obj/usr/ports/www/firefox-esr/work/.stage_done.firefox._usr_local" in /usr/ports/www/firefox-esr
*** Error code 1
warning: struct `ResultIter` is never constructed
--> /usr/obj/usr/ports/www/firefox-esr/work/firefox-140.12.0/third_party/rust/askama_derive/src/input.rs:611:8
|
611 | struct ResultIter<I, E>(Result<I, Option<E>>);
| ^^^^^^^^^^
|
= note: `#[warn(dead_code)]` (part of `#[warn(unused)]`) on by default
warning: `half` (lib) generated 21 warnings
warning: `serde_path_to_error` (lib) generated 1 warning
warning: `askama_derive` (lib) generated 1 warning
warning: `async-trait` (lib) generated 4 warnings
gmake[3]: *** [/usr/obj/usr/ports/www/firefox-esr/work/firefox-140.12.0/config/makefiles/rust.mk:528: force-cargo-library-build] Error 101
gmake[3]: Leaving directory '/usr/obj/usr/ports/www/firefox-esr/work/.build/toolkit/library/rust'
gmake[2]: *** [/usr/obj/usr/ports/www/firefox-esr/work/firefox-140.12.0/config/recurse.mk:72: toolkit/library/rust/target-objects] Error 2
gmake[2]: Leaving directory '/usr/obj/usr/ports/www/firefox-esr/work/.build'
gmake[1]: *** [/usr/obj/usr/ports/www/firefox-esr/work/firefox-140.12.0/config/recurse.mk:34: compile] Error 2
gmake[1]: Leaving directory '/usr/obj/usr/ports/www/firefox-esr/work/.build'
gmake: *** [/usr/obj/usr/ports/www/firefox-esr/work/firefox-140.12.0/config/rules.mk:359: all] Error 2
*** Error code 1
Stop.
make[1]: stopped making "/usr/obj/usr/ports/www/firefox-esr/work/.stage_done.firefox._usr_local" in /usr/ports/www/firefox-esr
*** Error code 1
AIが自律的にコード開発できるとか、AI任せでデバッグできる的な話が話題になり、AIに任せれば既存コードのバグ取りが無人化できるとの期待を語る人々が現れる今日この頃…
現在のLLM(大規模言語モデル)は、既存のノイマン型コンピュータで動いているはずなので、計算科学の文脈だとその能力はチューリングマシンやλ計算と同等(正確には、メモリの有限性で制約されたそれ)なはずで、タスクを解くLLMは、たかだか多項式時間でCなりFortran等のチューリング完全なプログラミング言語に変換できます (シビラシステムとかIAL社の量子サーバーとかなら前提が変わるかも…)
現行のLLMベースのコード開発自動化システムに任意性はもてないはずで…
例えば、量子計算機はNP完全問題が多項式時間で解けると証明されていないが、現時点では古典計算機より強力だと考えられているので、量子計算機上のLLMはそうしたハイパータスクを解ける可能性はまだ残っているはず…
カテゴリー: Admin | Emacs | EPICS | Fortran | FreeBSD | GCC | hgsubversion | IPv6 | KEKB | LHC | Lisp | LLVM | MADX | Ryzen | SAD | samba | tDiary | unix | WWW | YaSAI | お仕事 | イベント | 出張 | 宴会 | 数学 | 艦これ | 買いもの | 追記 | 雑記