Orz日記 by Akio Morita

_ [FreeBSD][Ryzen]Ryzen Threadripper 2950X

前回の続き

SuperKEKBの運転も終わったので、検証再開 make -j16 buildworld+buildkernelの連続負荷 48時間クリア 95時間クリア (2019-07-10 22:10)

変更点

• X399M Taichi Firmware V3.50へ更新 (3.22Aから)
• ラジエーターファンの配置変更(吸い出しから吹き込みに)
• FreeBSD 12-STABLE r349722へ更新

X399M Taichi/Threadripper固有設定のまとめ

• /boot/loader.conf

efi.rt.disabled=1
machdep.hyperthreading_allowed=0

efi.rt.disabled=1 12-CURRENT系で試験し始めたころのworkaroundなので今は外せる (2019-07-10 検証)

• /etc/sysctl.conf

# Ryzen threadripper 2950X Tctl offset
dev.amdtemp.0.sensor_offset=-27
dev.amdtemp.1.sensor_offset=-27

動作温度

前扉と2.5inchケージの隙間が狭いため、SSD/HDDベイの温度の方に大きな影響が出る模様

_ [Fortran]execute_command_line

waitが真(default)の場合、cmdstat引数を省略するとコマンドが見つからない場合、Fortran runtime errorでプロセスが終了する(gfortran8.3で確認)

waitが偽の場合は、cmdstat引数の有無に依らずexecute_command_lineは成功する (cmdstatの戻り値は常に0、exitstatは更新されない)

非同期実行時にエラーハンドルできなくなる理屈は理解できるが、動作が一貫してない気がする…

さらに調べると、Fortran runtime errorの発生条件は正確にはcommand not foundでは無くexitstatの戻り値で決まる模様(gfortran8.3の実装)

少なくともgfrotran8.2の実装では、exitsat=127だとFortran runtime errorとなる(exitstat=126も同様)

call execute_command_line('exit 1', exitstat=i)
write(*,*)'exit 1 -> ', i
call execute_command_line('exit 127', exitstat=i)
write(*,*)'exit 127 -> ', i

libgfotranをバラしてみるとそのものズバリのコードが

      /* Synchronous execution.  */
      int res = system (cmd);

      if (res == -1)
        set_cmdstat (cmdstat, EXEC_SYSTEMFAILED);
#ifndef HAVE_FORK
      else if (!wait)
        set_cmdstat (cmdstat, EXEC_SYNCHRONOUS);
#endif
      else if (res == 127 || res == 126
#if defined(WEXITSTATUS) && defined(WIFEXITED)
               || (WIFEXITED(res) && WEXITSTATUS(res) == 127)
               || (WIFEXITED(res) && WEXITSTATUS(res) == 126)
#endif
               )
        /* Shell return codes 126 and 127 mean that the command line could
           not be executed for various reasons.  */
        set_cmdstat (cmdstat, EXEC_INVALIDCOMMAND);
      else
        set_cmdstat (cmdstat, EXEC_NOERROR);

stdoutのredirectionまで考慮すると、自前でsystem(3)総統を実装すべきか？ (シグナル処理回りの可搬性が気になる所だが…)

_ [FreeBSD]TODOリスト

• samba4.10への移行
  • sysvol向けのNFSv4 ACLサポートらしいので、PDCを再構築してZVOLを放逐する
• postfixへの乗り換え
  • 秋にOCNが、送信時のSMTP-AUTHを必須にするので、postfixで実装し直す
  • qmailのSMTP-AUTH回りは、パッチの管理が面倒そうなので、これを機にpostfixへ乗り換える
  • まずは、localhost上のSMTPサーバーをpostfixで構成してみる
  • account-ext形式のアドレスサポートは、postfixには無いので要注意
    • 現在設定中の拡張アドレスのリストをまとめておく事

_ [雑記]PCラックの更新

設置スペースの拡張のためPCラックの更新を検討する

• 壁際のスペース幅100cmに新規にラックを導入し、現行ラックW60xD45xH120内の機材をすべて移設する
• 現行ラックは、物置として再利用する
• 新設ラックは、LuminousのW90xD45xH150規格を想定

発注前に調査すべき事

• ACタップ類も更新するため、必要な口数とケーブル長を検討する(UPS系・壁コン系に分けて集計すること)
  • タップの識別性改善のため、UPS系をロック付き・壁コン系をロック無しとするのはどうか？(もしくは、カラーマーカーを追加する)
• コンソール機材(Keyboard/Mouse/Display)接続ケーブルの必要長・配線経路の検討と資材発注
  • USB延長ケーブルx2・DVI-Dケーブル・Display電源ケーブル
  • オプションで、卓上ノートPC向けのACライン・LANケーブル
• 収容機材高に基づく棚の高さのデザイン
  • プリンタ・ADFスキャナの収容スペースは要検討
  • ADFスキャナに関してはスライド棚による実装も検討すべきか？
    • スライド棚の仕様は、耐荷重15kg、スライド長23cm
      • ScanSnap S1500 3kg/Deskjet 5551 5.7kg
      • ScanSnap S1500では、23cm引き出すと原稿トレイがギリギリラックから出てくる
  • Network Switch系の棚には、一部板張りすると便利
    • 19mmポール向けの w74xD30の棚板材が候補
• 機材搬出までに、ケーブル類にタグを付けること
  • LANケーブルは、機器名・Switchポート番号
  • KVMケーブルは、ポート名
  • ACケーブルは、機器名
  • 必要であれば、ラベル材を調達すること

_ [FreeBSD][Ryzen]Ryzen Threadripper 2950X

前回の続き

1. efi.rt.disabled=1は、不要であることを確認
2. shutdown -p nowで、電源が落ちない(状況は最初の同様)

(2)に関する類例の再捜索結果

2018-12-14に報告されている Bug 233998が状況的に一致する

• 12.0-RELEASE上のThreadripper 1950X + X399での報告
  • https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233998
  • https://forums.freebsd.org/threads/acpi-shutdown-not-working-on-amd-x399-threadripper.69065/
  • https://reviews.freebsd.org/D18506
• パッチは、13-CURRENTには入っているがバックポートされていない？
  • headからr342108を持ってくると問題が解決する(sys/contrib/zstdへのパッチは無関係)

残る課題は、SMT on状態での 32-thread動作の安定性の確認のみ 最近のSMT回りのセキュリティ問題やFP性能を考えるとbuild以外にはSMT不要だったりするが…

_ [FreeBSD][Ryzen]Ryzen Threadripper 2950Xストレステスト

調子にのって、workaround外した状態でストレステストしたら11時間で固まった模様

95時間のストレステストとの設定比較

• 共通の設定(SMT off)

machdep.hyperthreading_allowed=0

• 95時間クリア時固有の設定

1021: MSR 0xc0011029: 0x00000000 0x10e2a000 -> 0x00000000 0x10e2a000
1033: MSR 0xc0011020: 0x02068000 0x00000000 -> 0x02068000 0x00000010
1049: MSR 0xc0011028: 0x00140200 0x248000d4 -> 0x00140200 0x248000d4
1057: machdep.idle_mwait: 1 -> 0
1091: MSR 0xc001102d: 0x10000005 0x00000020 -> 0x10000005 0x00000020
1095: MSR 0xc0011020: 0x02068000 0x00000010 -> 0x02068000 0x00000010
1109: machdep.idle: acpi -> hlt

Firmware/Kernelの設定に対して追加で設定しているworkaroundは、1033, 1057, 1109の3種類となる

必要なworkaround設定は、sys/amd64/amd64/initcpu.c(MSR)とsys/x86/x86/cpu_machdep.c(sysctl machdep)に含まれているが、FAMILY 17hかつMODEL 01hでのみ有効にされているため、Zen+な Threadripper2が対象にならない(MODEL 08h)

また、Zen1ベースのThreadripper1はMODEL 01h/STEP 01h、EPYC1はMODEL 01h/STEP 02hで対象になる模様

Revision Guideのp.12 Table.8を読む限りはZen+なThreadripper2(PiR-B2)には、1033/1057/1109は該当しないとあるのだが、p.16 Table.10には Errata 1109が2nd Generation Ryzen processor(つまりZen+)に残っていると表示されてたりと一貫していないあたりが…

ともかく、必要なworkaroundの検証を進めてみる

_ [FreeBSD][Ryzen]Ryzen Threadripper 2950Xストレステスト

Errata workaround 1057/1109を外した状態でbuildworld/buildkernlストレステスト49時間をクリア

_ [雑記][Ryzen]冷却系見直し

• 排気ファン交換(流量当りの騒音低減)
• 筐体内のエアフロー改善のため120mmx15mmファン追加
  • PCIeカード類冷却
  • VRM冷却(水冷のため、CPUソケット周辺へのエアフローが弱かった)

負荷試験時の温度(CPU及びHDDケージ)が低下しているが、構成変更と 同時にSMT設定も変更しているので、温度に関しては純粋な比較にはならない模様

buildworld/buildkernel時間は、SMT offで19分に対しSMT onだと21分(first lap)に増えている

動作スレッド数の増大により、待ち合わせ等のオーバーヘッドが増えたか？ 消費電力は減ってる模様なので、実質稼働密度が低下している可能性がある

_ [FreeBSD][Ryzen]buildworld/buildkernel周回時間

測定結果をざっくりまとめてみる

• 同じ16並列buildだとSMT offに近い特性だが、lap timeは若干伸びている
  • thread schedulingでオーバーヘッドが発生する模様
• 32並列buildで温度が明かに低い(&遅い)のは、core稼働状態の変化でブースト動作が変わっているためか？
• Tdieは最大68℃なので、サーマルスロットリング限界ギリギリの動作点
  • EFRでブーストがかかった結果か？

このマイクロベンチマークの結果だと、buildworldやFP主体の並列計算用途だとSMT offの方が安定した性能が出せる模様

前扉開放の影響

前扉開放時の温度変化は、Tdieは1℃未満、Thddは-8℃

やはり、前扉とオープンベイ間のクリアランスが小さいのが効いている模様

一応、前扉閉でストレステスト中でもThdd~42℃程度なので、問題にはならない

_ [FreeBSD][Ryzen]Precision Boost Overdrive Offでのストレステスト

冷却系換装時の特性変化

Enermax LIQTECH 240 TR4(ELC-LTTR240-TBP) ラジエーターファンはNF-A12x25PWM x2に換装済み

Noctua NH-U12S TR4-SP3 + NF-A12x25PWM x2

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

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

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

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

• https://www.amazon.co.jp/gp/customer-reviews/R35DAC2X3E3Y7X/ref=cm_cr_dp_d_rvw_ttl?ie=UTF8&ASIN=B07511TK12
• https://www.amazon.com/dp/B074ZLQZG2/
• https://www.reddit.com/r/Amd/comments/9ikp03/enermax_official_response_to_liqtech_12_tr4/

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

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

Enermax LIQTECH 240 TR4(ELC-LTTR240-TBP)のピークアウト温度

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

ストレステスト再開後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のピークアウト温度の劣化を確認し、空冷化

_ [雑記][Ryzen]Ryzen Threadripper 2950X投入

何とか安定稼働するようになったので、Core i7 6700K/ASRock Z170M Extreme4なワークステーションと入れ替えで実戦投入

負荷時にそれなりに音が出るのは能力から仕方ないが、アイドル時も空調を止めてるとファン音が聞こえるので、もう少しファンの回転数曲線を調整する余地がある模様…

Core i7機はケースが古いので、新しいケースで再整備後に転用予定だが、用意していたAntec P5が不良品だった…リベット止めが正しく行われてなく歪んでいるため2.5inchケージが動かせないっぽぃ

_ [雑記]ラック用の資材到着

発注していた新ラック用の資材が届いた…

場所塞ぎなので、さっさと作業場を確保して組み立てないと