ToDo:
OCN開通、接続試験開始
B-Flet'sへの切替え後に、speed.rbbtoday.comで上り下りを測定してみます
B-Flet's(ハイパーファミリー) 物理回線速度 下り(ISP→PC): 100.0Mbps 上り(PC→ISP): 100.0Mbps 1回目 下り(ISP→PC): 28.53Mbps 上り(PC→ISP): 14.41Mbps 2回目 下り(ISP→PC): 32.38Mbps 上り(PC→ISP): 16.45Mbps 3回目 下り(ISP→PC): 32.46Mbps 上り(PC→ISP): 16.73Mbps 4回目 下り(ISP→PC): 32.69Mbps 上り(PC→ISP): 16.13Mbps 5回目 下り(ISP→PC): 32.15Mbps 上り(PC→ISP): 16.72Mbps
上り帯域は、Flet's ADSLの8倍程度出ているが、なぜに下りの半分 Orz
裏でOpenOffice.org 2.0.4rc3を buildしているだけなんだが.... それが非対称の原因とは思えない
やっぱり、ipfwのdivertルールが原因なのでしょうか? out側が 2ルール、in側が 1ルールなので 上り時には 1パケット当たり一回コンテキストスイッチが増えてしまいます
時間が出来たら、ipfw+natd+tcpmssdから pfに置き換えて MSS/NAT処理を kernelに移したいところだ
mpdの tcpmssfixフラグを enableしてもMSSが修正されないので tcpmssdが必須な罠
POSIX semaphores(sem(4))の実装で使われる kernel semaphore資源 (SEE ALSO ksem_* system call)が、FreeBSD 7.1ではリークするようです。
pthread時には、sem_init(3)等の関数は、プロセス間共有でなければ posix thread library側に有る semaphoreコードに委譲される訳ですが、 -pthread付きでコンパイルして-pthread無しでリンクして 出来た変なC++実行ファイルを何度も実行しているとsem_init(3)に 失敗して abortするようになります。 おそらく、static object生成時の排他制御のために最初にsem_init(3)するが、 途中からPOSIX thread libraryがロードされて、sem_*が thread library側に 切り替わり終了時の sem_destroy(3)がksem_* system callを呼び出さない ためと思われるが、sem_init(3)で生成した名前無しセマフォが 関与するプロセスがすべて死んだ後に生き残っているのは、 カーネルのリソースリークな気がする。 (名前無しなので、アタッチしているプロセスが無くなると 開放手段(sem_destroy)で使うsem_t構造体が無くなる)
マザーにCPUとクーラー本体取り付け後、ケースに入れる手順だが、 バックパネル裏に配置されているCPU12V 8pinコネクタの作業性がかなり悪い
CPU12V 8pinコネクタ周辺はVRMのヒートシンクに囲まれるので、天板が外れないケースの場合、手を入れるスペースが確保出来ない
マザー固定前に少しずらした状態でコネクタを接続して置くのが正解の模様、 天板が塞がっている場合、下側からのアプローチする形になるので、NH-U12Aだと排気側のファンを外しておくと作業しやすい
あと、ROG CROSSHAIR X670E GENEの場合、M-ATXのPCIe最上段スロット右側のネジ穴がロックリリース機構がレイアウトされて潰れているので、ベースから受け座を外しておくこと
とりあえず、拡張カード/ストレージ無しの状態にType-C alt mode→HDMIアダプタ経由のコンソールで起動試験実施
UEFI設定画面を確認して、メモリ回りのAMD EXPO設定を有効にしてから、memtest86開始
memtest86動作中のCPU温度(POST LED)とシステム電力(ワットメーター)は、50℃/150W ～ 60℃/190W
同一ケース・同一ファンの運用機より排気音が少しうるさいのだが、 どうもマザー上のファンコネクタだが、CPU関連とケースファン1系統以外はフルスピード固定の模様
4pinファンコネクタだがマニュアル上の名称がFS_FAN#なので、初期設定というより回転数制御自体が未実装の模様
必要なら負荷試験の様子を見ながら、排気側ケースファンにLNA追加して調整かなぁ…
フロント吸気系をCHA_FANPに、バック排気系をCPU_OPT(CPU_FAN連動)に配線変更
13.1-RELEASEのインストーラUSBだと、atkbdc0とuart0を認識したところで停止してしまう模様
あとで、13-STABLE/SNAPとか14-CURRENTを試してみよう…14-CURRENT 2022/09/30 n258315のmemstick版も同じ所で固まる
Ryzen 5950Xで動いているFreeBSD 13-STABLEのdmesgからの類推だと、その後はhwpstate周りなのでcpufreqドライバ周りの対応が必要？
動作テスト用のWindows10環境を構成して、OCCT11.0.12にてテスト実施
なんか、FP回りの動作が不穏
他のLinpack系テストツールでもエラーが出ており、Ryzen MasterでECOモードなどでクロック・電力制限をかけた状態でも再現している
MultipassなLinpackテストだと、passとFAILが両方あり、passのケースではresidual一定(計算が所定の誤差で再現している)だが、FAILのケースのresidualが一定していない(計算毎に結果がバラついてる)
電力不足を疑いCPU 12V 8pin x1を x2に増設したところ、JEDEC Normal/OCCT Linpack AMD64では出なくなった模様前回と違い開始1分では出ないが、10分過ぎた辺りから発生し始めた
当然だが、CPU 12Vライン改修直後はコールドスタートなので、コンポーネント温度が原因？
CPU温度に関しては開始直後に飽和しているで、それ以外のコンポーネントか？
電源電圧の不安定化であればVRM温度、CPU以外でベンチマークコードの実行結果に直接関わるのはものは、メモリーバス(バックプレーン)とDDR5メモリ本体(データ化けが起こっているのならば説明が付くが、memtestでかからないのはなぜ？アクセス頻度の違いで稼働温度が異なるのか？)
状況的にCPU向けの12Vラインが、FP負荷時の容量不足による不安定化してるぽぃが、マザーのマニュアルではCPU 12V 8pinの接続はx1 or x2と記述されており、TDP枠からの要求が記述されていないのでドキュメントのミスな気がする
マザーごと換装するケースでは、既設のCPU 12V 8pin x1を流用してハマる臭い(TDP105Wの 7700X/7600Xは問題ないのかも)
LinpackベンチでFAILが出ている状況とDIMM周りをブロアで吹いた状況でLinpackベンチがpassする状況(まだ積算時間が短い)を比較してみたが、 DIMM SPD Hub Temp.にて40℃未満はpass・45℃以上だとFAILしているように見える
検証用のファンを設置して長時間試験を企画中…
カテゴリー: Admin | Emacs | EPICS | Fortran | FreeBSD | GCC | hgsubversion | IPv6 | KEKB | LHC | Lisp | LLVM | MADX | Ryzen | SAD | samba | tDiary | unix | WWW | YaSAI | お仕事 | イベント | 出張 | 宴会 | 数学 | 艦これ | 買いもの | 追記 | 雑記