トップ «前の日(09-14) 最新 次の日(09-16)» 追記

Orz日記 by Akio Morita

ToDo:

  • 15 SAD Fit[]回りの障害事例の解析
  • 10 smart pointer版PEGクラスの再実装(Left Recursionまわり)
2006|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|06|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|07|08|09|10|11|12|
2013|01|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|06|07|08|10|12|
2016|01|02|03|05|06|08|10|11|
2017|01|02|03|04|05|06|07|09|10|11|12|
2018|01|02|03|04|06|07|08|09|10|11|12|
2019|01|03|04|05|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|12|
2024|01|02|03|04|05|06|07|08|09|10|11|12|
2025|01|02|03|04|05|06|07|08|09|10|

2008-09-15

_ [LHC]運休中 Orz

冷凍系の作業で水曜日まで運休中

_ [SAD]newlibだめだめ Orz

Cygwinのエラーの件だが、 GCCのソースを読み進めて行くと、-std=オプションを使って ISO Cを指定したり(例えば-std=c99)、-ansiオプションが 設定された場合、cppにてマクロ__STRICT_ANSI__が 自動的に定義される(参照: gcc/c-cppbuiltin.c)。

ここまでは問題無いのですが、Cygwinの newlib付属のヘッダー群は、 __STRICT_ANSI__定義時にそれなりの数の関数の定義が無効になる と言う動作をしています。

FreeBSDのヘッダー(newlibの元ネタは BSD libc)を覗いてみると /usr/include/sys/cdefs.h当たりで !defined(__STRICT_ANSI__) || __STDC_VERSION__ >= 199901 といった使い方をしています。 意味的には、__STDC_VERSION__199901未満 (つまり、ISO C99以前)かつ、 __STRICT_ANSI__が定義されているときに、 以降のヘッダー宣言が無効になるというものです。

__STRICT_ANSI__定義時は、厳格なANSI規格に適合しない コードを除外しているわけだが、ISO C99な関数の宣言まで無効になっている ということは、newlibヘッダーは最新の規格に追従出来てないということ。

と言う訳で、CygwinでコンパイルできないのはSAD側のソースの問題ではなく Cygwinが標準規格に追従出来ていないのが主原因と言える。


2010-09-15

_ [SAD]テスト・テスト・テスト

表題のとおり、環境毎の構築試験と修正を実施

以下の環境は動作確認が取れました

  • 巫女 GNYO/Linux 4.2
  • NetBSD/amd64 5.0.2
  • DragonFly BSD/i386 2.6.3

未テストですが、NetBSD/i386 5.0.2も問題なく動くと思われます。

OpenBSDに関しては、ports/lang/gccが GCC 4.2.4なのでテストしていません (少なくとも GCC 4.3.x以降でないと amorita branchは動かない)

DragonFly BSDでも使っている NetBSD pkgsrcでの問題点を 以下にまとめておきます。

  • DragonFly BSD/x86_64では pkgsrc/lang/gcc44はコンパイル不能
  • DragonFly BSD/i386用の 2010Q2 gcc44 binary packageがバギー
    • -fPICが動かない(-fpicは動くし、ccなら-fPICが動く)
    • libgfortran.so.3にdynamic linkされているlibgcc_s.so.1への runtime library path情報が欠落しており ld-elf.so.1が runtime linkに失敗する
    • libgfortran.so.3が、libmで未実装のscalbnl関数シンボルを参照している
  • NetBSD/amd64の 2010Q2 gcc44 binary packageがバギー
    • gfortranが、libmで未実装のhypotl関数シンボルを参照するコードを生成する

少なくとも試した範囲では、ISO C99実装はFreeBSD/Linuxが 一番進んでいるようです。

ISO C99の未実装について

  • NetBSD 5.0.2
    • ISO C99 double precision math function fmin/fmaxが未実装
    • ISO C99 long double precision math function hypotlが未実装
  • DragonFly BSD 2.6.3
    • ISO C99 long double precision math function scalbnlが未実装

2025-09-15

_ [雑記]ARCTIC Liquid Freezer III Pro 240導入

最近のAIO水冷クーラーは240mmクラスでもハイエンド空冷並に冷えるらしいので、Antec P5に詰め込んであるRyzen 9950Xシステムの冷却系をRZ-620改から液冷化してみた

筐体側都合で240㎜ラジエーターまでなので、 熱交換体積が一番大きいARCTIC製を選択 (来年以降だとnoctua水冷も検討候補か?)

以前、Ryzen Threadripper 2950X導入時に実装した SP3/TR4専用240mmラジエーターAIO水冷はTDP250W対応を謳うのに、 実働だとnoctua NH-U12S TR4-SP3(NSPR 129)よりも 10度以上平衡温度が高かったうえに、 1週間の連続稼働で平衡温度が上昇してゆく代物だったので、 実働検証を丁寧にやる予定

バラックテスト

水枕を取り付けラジエーター本体を筐体外に置いた状態で全力運転試験実施

  • RZ-620改の全力運転時よりも冷えることを確認
    • 標準実装のP12 Proの全力運転はすごくうるさい
    • バラック状態だとP12 Pro → NF-A12x25 G2 PWMに換装しても性能変わらず
      • 最大静圧は半分程度になるので流路抵抗が大きいケースでは差が出るはず
    • 正確には、PBOなので同一平衡温度でCPUベンチマークにてRZ-620改に対して1~2%優勢なスコアを達成

まともに冷えてよかった

ケースへの実装

  • P5吸気口への実装では静音性優先で、手持ちのNF-A12x25 G2 PWM Sx2-pp 2セットのプッシュプルな静圧ブースト構成 (実用静圧当たりの騒音は低減するはず…)
  • FAN系統ごとのPWM特性と騒音値を検証実施
    • P5内部に封じ込めるとARCTIC VRMファンは全力運転でも最大39.3dB程度で無視できる(背景雑音レベル〜38.1dB)
    • 同ポンプ雑音は背景雑音レベル以下の模様
    • 一番耳障りなのは、ケース後方のNF-A12x25 G2 PWM排気全開時の風切り音
      • ケース前方上方での音圧測定では、同一仕様のラジエーターファンと同回転域で+1.5dB程度悪いのは、ラジエータファンは前方にフィルターチャンバー・遮音扉などの構造物で吸音・遮音されるからか?
      • 昔あった排気用サイレンサーダクトとかつけると低減出来るかなぁ?
      • パンチングメタルのファングリルを切断してファンガードに入れ替えるのも案だが鉄ケースなので加工がしんどい (アルミケースなら割と簡単にできるのだが…)

初期調整の結果

現時点の調整で、PWM60%制限でRZ-620改の全力運転時とほぼ同等のベンチマーク性能を背景雑音レベル +1dBレベルで達成し、CPUフルロード時の騒音レベル低減に成功したので、まずまず成功か?

85℃ PBO設定なので最大負荷時の平衡温度は 85〜86℃で変わらずだが、アイドル時の Tdieは 45 → 35℃ (-10℃)へ低減した

ストレージ系への影響

  • CPU/PCIe間のm.2 NVMe SSD温度
    • アイドル時の平衡温度 43℃ → 39℃ (-4℃) - 大型CPUヒートシンクと言う至近熱源の排除とそれに伴うエアフロー改善効果(m.2ヒートシンク直上をCPUヒートシンクが塞いでいる構造からオープンスペースへ変わった)と思われる
    • 最大負荷時の平衡温度 48℃ → 45℃ (-3℃) - 順当な改善の範囲か?熱源が筐体吸気ポート設置のラジエータへ移って、筐体吸気温度が上がるので劇的な改善にはならない模様
  • 5インチベイ上のSSDケージ内のSATA SSD温度
    • アイドル時の平衡温度 37℃ → 38℃ (+1℃) - 筐体の吸気バランスの変化 or 吸気ラジエータの熱で筐体内でケージが温められている?
    • 最大負荷時の平衡温度 38℃ → 44℃ (+6℃) - プッシュプル構成で増圧した吸気ラジエータ系でケージ側の吸気が阻害された or 吸気ラジエータの熱で筐体内でケージが温められている
      • 前者であれば、ケージ冷却ファンの増圧による吸気バランス調整やドア開放による吸気コンダクタンスの改善で下がるはず (要検証)
        • ケージ冷却ファンは40mmx40mmx28mm仕様なので現在市場では入手性が悪いのが問題 (以前あったワイドワーク扱いの製品流通が途絶えた)
      • 後者に関しては、エアフローが分離できていない構造上の問題
      • 最大温度45℃以下なので、実用上支障はないはず

2.5インチSSDケージに許容可能な温度上昇があるが、Gen4 NVMe SSDのピーク温度が低減した

CPU負荷とP5 ドア開閉の影響を測定してみた

TairTnvmeTsataLoadDoor
25.7 37.0 31.0Idle Open
25.5 46.0 33.0Full Open
25.3 47.0 44.0FullClose
25.3 39.0 38.0IdleClose

ドライブケージのSATA SSD温度は、扉開閉の影響が大きいので、コンダクタンスの悪さから プッシュプル化されたラジエーターにエアフローで負けている模様なので、 ドライブケージの排気ファンを増強すれば改善すると思われる

ただ、ドライブケージのファンは40mm角 28mm厚なのだが、 ワイドワーク扱いのコネクタ付き製品の流通が終わってしまったので、 モノタロウ辺りで山洋ファンを調達してコネクタを自分で圧着する必要がある


カテゴリー: Admin | Emacs | EPICS | Fortran | FreeBSD | GCC | hgsubversion | IPv6 | KEKB | LHC | Lisp | LLVM | MADX | Ryzen | SAD | samba | tDiary | unix | WWW | YaSAI | お仕事 | イベント | 出張 | 宴会 | 数学 | 艦これ | 買いもの | 追記 | 雑記