Orz日記 by Akio Morita

_ [雑記]LHC LUMI 2006会場より

会場の無線LAN経由で書き込みテスト

録画マシンのWinXPのエクスプローラが制御不能に成ってる(X_X;; 2週間分の番組がとんだか...Orz

_ [雑記]E Drive逝ったか?

いまだに、ログアウトの途上に有るWinXP...いっそリブートしてくれた方が どれだけましか...Orz

しかも、Driver Eの MFT保存に失敗したとか何とか言うメッセージが... タイミング悪過ぎ Orz

_ [LHC]LINAC4起工

LHCの入射器アップグレードの一つである LINAC4の起工式が行われた模様。 何でも、所長自らショベルカーを操縦したそうだ。

_ [KEKB]運転再開

日本時間 18時48分現在、HERにビームが溜まっているようだ。 夏期メンテナンスからの立ち上げとしては順調の模様...

_ [雑記]台風一過

台風は通過したものの風は強いままなので、昼前にゆっくり出勤

これで、秋が深まるのかなぁ…

_ [SAD]解析メモ

頻出コード

a=min(.99d0,px(i)**2+py(i)**2)
dpz=a*(-.5d0-a*(.125d0+a*.0625d0))
dpz=(dpz**2-a)/(2.d0+2.d0*dpz)
dpz=(dpz**2-a)/(2.d0+2.d0*dpz)

dpz := Sqrt[1-s] - 1 (但し、s := px^2 + py^2, 0 =< s < 1)を 3次まのでマクローリン展開を種に2回Newton改良を行った近似式

ハードウェア化された開平器がある場合は、素直に計算した方が早いかも...

この場合、s〜0近傍の桁落ちを考量し、dpz := -s / (1 + Sqrt[1 - s])で計算する方が良い(除算一回分不利)

Rythen Threadripper 2950X(Zen+)で、DRIFTを大量に詰め込んだ状態でベンチマークで比較したが、 Newton改良2回のコードと-s/(1+sqrt(1-s))では有意な差が出ない(-O3 -ffast-math時)

コードの改変に対するCPUタイムの変化を調べてみたが、

• Newton改良の段数を減らすと有意に早くなる
• sqrt(1-s)-1は、-s/(1+sqrt(1-s))より有意に早い (Newton改良1回と2回(標準コード)の中間ぐらい)

有意な差がでるので、ボトルネックにはなっている模様

ちなみに、-ffast-mathを外すと-s/(1+sqrt(1-s))はNewton改良2回のコードよりも有意に遅い

全域での精度を考えると、-ffast-math付きでsqrtを使う方が良さそう…

DISKINパラメータの挙動

DRIFTとQUADに実装されているが、動作が異なる

• DISKIN DRIFT
  • SOL区間では、DISKINが無視される
  • SPACフラグ時は、DISKINが無視される

• DISKIN QUAD
  • SOL区間では、DISKINが無視される
  • K1 == 0で帰着するDRIFTは、DISKIN = 0な DRIFT (DISKINが効かない)
  • K1 -> 0の極限で帰着する DRIFTは、DISKIN DRIFTと写像が異なる(少なくとも x, yの px, py依存性は異なる)

APRETの謎機能

• JDPX, JDPYパラメータが設定されている際に発動する機能
  • ax := Min[|DX1|, |DX2|], ay := Min[|DY1|, |DY2|]で定義される楕円APERTureの外側の粒子を、x,y座標については楕円(ax, ay)上、px,py座標については楕円(JDPX, JDPY)上にランダムに再配置して、g座標のDPに加える
  • g座標更新に伴う随伴するdv座標は更新されない(一貫性が損なわれている)
  • 作用する際の入力-出力間の関係に因果性が無い
• LWAKE, TWAKEフラグ時に、DX1,DX2,DY1,DY2によるクリップ動作になる
  • 粒子数が変わるとWake計算コードに不具合が有るのか？
  • 物理的な意味論が不自然(現実にはロスは発生する)

_ [Ryzen]16コアRyzenで作ったAntec P5マシン達

Antec P5に夢とロマン(16コア)を詰め込んだマシン達

初号機

Ryzen Threadripper 2950X + ASRock X399M Taichi

筐体の吸排気系は、吸気側 NF-A12x25 PWM x2、排気側 NF-A12x25 PWM x1

CPUクーラーは、最終的には Noctua NH-U12S-TR4-SP3の標準ファンを NF-A12x25 PWM x2に換装して、NH-U12S DX-3647相当に改修したものを使用

Noctuaの公式データだと、 ノーマル状態のNH-U12S-TR4-SP3は NSPR 129に対して、NH-U12S DX-3647は NSPR 157

実際、公称TDP 180WのRyzen TR 2950Xを冷やし際、 最初に導入した TR4対応水冷ヘッドでTDP250W対応を自称していた簡易水冷 ELC-LTTR240-TBPに対して、 我がNH-U12S-TR4-SP3改は、連続負荷状態でのTdie平衡温度 -10℃を叩き出している(240mm簡易水冷より冷えた＆静かだった)

CPU挿入したらTR4ソケットの蓋がしまらないエラッタ品を掴んだのはいい思いで(解禁当日昼に購入、持ち帰り不具合発覚、当日夕方にショップに持ち込み初期不良と認定され交換対応)

マルチスレッド負荷でハングアップする系のCPUエラッタもあり、安定稼働するAGESAファームが出てくるまで実用に耐えなかった…(ファーム出た後は安定したのだが、検証作業を行う時間が取れなくて実戦投入が遅れた)

二号機

Ryzen 5950X + ASRock X570M Pro4

筐体吸排気は初号機を踏襲、CPUクーラーはNoctua NH-U12A

マザーはZen2時代から存在していたもの ＆ NSPR 169に対してTDP 105Wなので大きなトラブルもなく簡単に仕上がった

ASRock X570M Pro4は、UEFIファームに入るところが微妙に不安定でじゃじゃ馬(ホットリスタートからUEFI画面に入るところで相応の確率で固まる、コールドスタート時はOKっぽぃ)なのですが、それ以外は問題なく動きます

同じX570マザーでもATXサイズの Gigabyte X570 AUROS PRO(Ryzen 3700X運用)にはそんな挙動は無いので、ファームのバグなのかなぁ…(癖が分かっていれば対処できるので致命的ではないけど…)

三号機

Ryzen 7950X + ASUS ROG X670E GENE

筐体吸排気は初号機を踏襲、CPUクーラーはいつものNoctua NH-U12A

マザーへの配線(CPU 12V 8pinx2)で苦労したのと、出荷状態の初期ファーム(グローバルの解禁日前日にβファームが出てる時点で察するべきだった)だとメモリI/O負荷をかけるとぼろぼろデータ化けする以外は初物にしては大きな問題なく立ち上がった

TDP 170W(PPT 230W)だけど、数値計算用なので SMT offで16コアの並列FP負荷を想定したLinpackによる負荷試験だと平衡状態で Tctl～95℃・PPT 80%・TDC 100%まで回った実績あり (Ryzen Masterで見る限り、4.9～5.1GHz辺りが出ているようなので満足)

マルチコアのメモリテスト負荷だと、PPT 80%にも届かずにTDC100%までいくので、DDR5インターフェースが電気食べてる？

メモリ構成は、AMD EXPOなDDR5-5200 OCメモリなのでその影響もあるかも？

本番環境投入前の各種ベンチマークから、手元の実用負荷だと1号機とほぼ同等の電力枠で、シングルスレッドの数値計算で2倍、並列コンパイル負荷でほぼ3倍の性能が出ている(Zen+/12nm → Zen4/5nmなので電力効率が全然違うのは当然なのだが…)

_ [雑記]NTP offsetジッターの件

とりあえず、現状までに分かったことを纏める

• Ryzen 9 9950X/B650M PG Riptide Wifi環境で、同一ネットワーク内のGPS付きNTP serverとのNTP offsetが不定期に300msecほどずれる
  • 2024/09/14頃から発症し、現在も続いている

• 使用マザーASRock B650M PG Riptide WiFiのFirmwareリリース日

• 同一ネットワーク内ノードまとめ
  • A - Ryzen 9 9950X機 (問題のノード)
    • インターネットGatewayとして運用している
      • 2024/08/30頃にRyzen 9 7950Xから9950Xに換装している
    • (B)への経路は、LAN内の10G core switch経由 (Connext-X6 -DAC-> Switch -CAT.6A-> (B))
    • nict.go.jpへの経路は、インターネットプロバイダ経由 (RTL8125(100BASE-TX) -Cat.6A-> ONU)
    • nict.go.jpと(B)および予備のGPSレシーバでNTPを構成すると、nict.go.jp・GPSを基準に、(B)のoffsetが不定期に+300msec飛んで見える
      • (B)のoffsetは±0付近と+300msec付近に二値化しているように見える
    • sysutils/clockspeedに含まれるsntpclockで、(A)の時計を基準に(B)のNTP時刻を観測すると、24時間以上連続で±1msec内のoffsetで安定している (1秒周期の観測)

• • B - GPS NTP server
    • GPS 1PPSとnict.go.jpに同期しているNTP server
    • (A)への経路は、LAN内の10G core switch経由 (I-225V -Cat.6A-> Switch -DAC-> (A))
    • 外部ネットワーク接続自体は、(A)をgatewayにしている
    • nict.go.jpとGPS 1PPSは±1msecで同期しており、offsetの日格差も小さい

• • C - Ryzen 9 7950X機 (テストノード)
    • (A)と同型のマザーボードを搭載した試験機
    • (A),(B)への経路は、LAN内の10G core switch経由 (RTL8125(2.5GBASE-T) -> Switch -> (A) or (B))
    • nict.go.jpへの経路は、(A)をgatewayにしている
    • nict.go.jpと(B)でNTPを構成すると、nict.go.jpと(B)へのoffsetは追従している
      • (A)のようなoffsetの不定期な飛びは見られない (連続的な変動は、7950X機側のクロックドリフトの模様)

• 調査まとめ
  • (A)のConnect-X6インターフェースの遅延ばらつきとは考えにくい
    • (A)以外のnict.go.jpの通信で影響が出るはず
    • sntpclockによる(A)-(B)間の観測結果と一致しない
  • (A)にて(B)のNTP offset変動時に、(A)および(B)ではGPS offsetの変動が観測されていない
    • (A)および(B)のローカルクロックは問題なく同期している (先のsntpclockの観測事実と整合する)
  • 観測されるoffsetの飛びの幅と符号が一定である (約 +300msec)
  • (A)と(B)のNTP clientとしての違いは、マザーボード・メモリ等に欠陥が無ければ、CPUモデル・使用NICとGatewayであるか否か (OSは同一)

現状の調査状況からは、ntpdのソフトウェアのバグもしくは、NTPDがやりとりするNTPパケット(UDP port 123→port 123)の混線((A)がNAPTな外部Gatewayなのでパケットがあつまる)あたりしか原因が思いつかん Orz

時間が取れたら、RTX830を本番投入してGateway機能を分離してみよう…NTPパケットの混線ならこれで治るはず