Pythonのアップデートをフォロー出来ない
Python側からのSAD呼び出しまわりのコードが保守しきれない
- 度重なる変更で、時代遅れになっていた(呼び出し側と呼び出し先が整合しない)
- 構文レベルの修正は行ったがテストが出来ない
実際に使っているユーザーが不在(声が聞こえてこない)なので、保守するメリットを見出せない

などです。要するに、長らくまともに動いていない＆声が上がってこない機能なので切り離しても良いだろうという判断です。

通信量が多いとか内部データ構造へのアクセスや内部APIを叩く必要が無ければ、外部プロセスとして pythonを立ち上げてpipeや network経由で通信で十分だと思うのですが、どうでしょう？

もしも、SADに Pythonインタープリターを組み込む必要が再び出てきたなら、界面設計あたりからやり直して dynamic loading moduleで実装すると言うことで...

CVS MAIN trunkにはなんかコードが入ってますが、原因が POSIX/SUS等の標準ライブラリの不足に起因する話なので、amorita branchとしては サポートしないという方針で行きます。

2019-07-15

冷却系換装時の特性変化

120x240x35mmラジエーターが体積の小さい空冷クーラーに明かに負けている…

条件的には、NH-U12Sの方はケースに導入された空気に触れているのにたいして、水冷ラジエーターは直接吸気された外気に触れている点で、低温熱源温度は水冷のELC-LTTR240-TBPの有利なはずなのだが…

調べた範囲では、ラジエーターの送出側は十分冷えているので、冷媒-CPU間の熱抵抗(熱交換器)性能で負けているとか論外Orz

第一世代のLIQTECH(TR4を含む)と第二世代の初期ロットの冷媒不良で冷えない/すぐ壊れる等の報告事例もあるようなので、あかん奴引いたかなぁ…

明かに、NH-U12S TR4-SP3の方が安定した性能出ているし、水漏れ等のリスクも無いので、空冷化改装決定ですw

以前のテストでも見かけたが、SMT on状態の32thread時に消費電力・温度が下がる現象は何だろう… 温度域からはサーマルスロットリングには見えないのだが…？？

buildworld/buildkernelによるストレステストによるCPUへの連続負荷と対応するTdieの推移 CPU負荷

ストレステスト再開後4日(7/7~7/10)でピークアウト温度が10℃上昇している。開始直後の53℃前後のTdieは、購入直後の運用データとほぼ一致する。(環境温度が24℃前後なのでほぼ整合)

この間、筐体の設定変更は無く、部屋の空調は連続稼働中なので、極端な変動は無いはずだが…

一部で報告されている冷媒劣化現象か？

ELC-LTTR240-TBPの積算稼働時間は、購入後3~4週間のはず

2018年9月1日購入、9月に1週間前後稼働させるも、Hangup系の不具合が治らず一時作業中断
2018年12月下旬にFirmwareをbeta版に更新、12.0-STABLEベースに更新して負荷試験1週間程度実施(Hangup系の不具合完治せず)
2019年7月、Firmwareを最新releaseに更新、12.0-STABLEを更新して、10日程度の負荷試験を実施して、安定化を確認するもTdieのピークアウト温度の劣化を確認し、空冷化

2020-07-15

ThreadripperのPRO版と言うより、EPYC2 RomaのTDPリミッタ解除版だよね

PCIeのレースや、Registered/Load Reduced DIMMサポート的には、EPYC2と同等設定で、Workstation筐体を前提にTDP制限を緩めて動作クロックを上げてきているっぽぃ