Orz日記 by Akio Morita

_ [SAD]分離すべき関数

機能毎のSADScript関数の切り離しを行うために汎用で参照される関数を 分離する必要がある

取り合えず、現時点で判明している範囲は次のとおり

• src/tfFileIO_.c
  • cfexptilde_
  • expand_tilde
• src/tfDynamicLink_.c
  • dl_* MI backend
• src/tfBuildInfo_.c.in
  • sadpkgdir_
  • check_build_info
  • sad_pkg_root,build_info_table等のデータベース

作業方針

• cfexptilde_は、src/utils.cに収容(Fortran用だし)
• expand_tildeは、src/sim/sad_api.cへの収容が妥当かな？
• dl_* MI backendは、src/sim/dynl-mi.c辺り？(プロトタイプヘッダは、既にsrc/sim/dynl.hがある)
• BuildInfoに関しては、Feature系同様に独立したframeworkにする(src/buildinfo.[ch]かな？)
• sadpkgdir_は、src/utils.cにてframework呼び出しで実装すべき

多分、src/sim/unix_env_.cの中身も src/utils.cと同じく Fortranコードへのユーティリティー類なのでマージすべきかな？

_ [SAD]SAD->MADX変換

変換精度が出ないエレメントをEmittance[]からtransfer matrixを切り出して matrixで埋め込む作業を始めたのだが、絶賛嵌まり中

SOL内部でSOL/MULT/SOL/MULT/...なチェーンが組んであるとき、 SOLは厚みが無いので、次のMULTの入り口と同じ状態にないと いけないはずだが、Emittance[]から切り出した ClosedOrbitとTransferMatricesは、一つ前のMULTの入り口と同じ値に見える。 多分、SOL内部の計算がtturneからtsoleへ移譲されているが、 演算結果の格納形態が完全互換になっていないように思える。 こいつは、ソースコードを要確認。

取り合えず、次のエレメントを探すコードをハックしてSOL内のMULTを matrixへ展開してみたのだが...結果が全然違う Orz

何が起こっているのだろう？

取り合えず、次の課題は...

• matrixへの展開コードの健全性を別のエレメントで検証する
• SOL内部の転送行列とビーム行列の変換と格納コードを検証する
• 現在省略している DRIFTエレメントのパラメータ展開をサポートする(SOL/DRIFTに転送行列を渡す必要が...)
  • 別案としては、軌道と転送行列を返すハッシュ関数への参照を渡すと言う解も有り

_ [FreeBSD]8.0-BETA3導入

Note PCを 7-STABLEから 8.0-BETA3へアップデートしたのだが、 無線LANデバイスの使い方が変更されていて、なぜ繋がらないのか 暫く悩んだ Orz

あと、カーネルインターフェースまわりの変更が原因だと思われるが、 7-STABLEで作ったhaldが100%負荷で走りっぱなしになる。 UPなシステムでは要注意

_ [FreeBSD]8.0-BETA3のATAPICAM壊れてる？

atapicam付きのカーネルで起動した際に、camデバイスのprobe/attach辺りで panicするようで...壊れてるのかな Orz

# kldload atapicam.ko
Fatal double fault:
eip = 0xc0485b69
esp = 0xd6377e04
ebp = 0xd6378284
cpuid = 0; apic id = 00
panic: double fault
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper(c3565b40,0,0,0,c0bed7b0,...) at db_trace_self_wrapper+0x24
panic(c0b0443c,c0b0442c,0,0,0,...) at panic+0xfe
dblfault_handler() at syscall
--- trap 0x17, eip = 0xc0485b69, esp = 0xd6377e04, ebp = 0xd6378284 ---
scsi_action(c359a000,c35cde80,c3591000,c35910a0,33da86ce,...) at scsi_action+0x9c5
probestart(c35cde80,c359a000,c359a000,c369c780,c369c740,...) at probestart+0x1589
xpt_schedule(c35cde80,5,1,c3412000,1,...) at xpt_schedule+0x1f2
proberegister(c35cde80,c3412000,c3412000,0,c0acbbe2,...) at proberegister+0x19a
cam_periph_alloc(c04836fb,0,c04836e4,c04866c0,c0acbbe2,0,c3570390,0,0,c3412000) at cam_periph_alloc+0x452
scsi_action(c3412000,c3412000,c3570390,5) at scsi_action+0x991
scsi_action(c3574000,c35702d0,5,ffffffff,ffffffff,...) at scsi_action+0x7ce
reinit_bus(d6379988,0,2,ffffffff,ffffffff,...) at reinit_bus+0x1c5
atapi_cam_attach(c35cdd80,d63799d4,c075b8d5,c0b93ca4,c35cdd80,...) at atapi_cam_attach+0x21e
device_attach(c35cdd80,c33b5c80,c361a0dc,d6379a20,c075bfd1,...) at device_attach+0x241
bus_generic_driver_added(c33b5c80) at bus_generic_driver_added+0x14f
driver_module_handler(c356ce80,0,c361a0c4,c0b93270,c0ad0fc8,7b) at driver_module_handler+0x18c
module_register_init(c361a0ac,c3487aec,c3565b40,c3591800,c33dbd00,...) at module_register_init+0x8c
kldload(c3565b40) at kldload+0x1519
syscall(d6379d38) at syscall+0x265
Xint0x80_syscall() at Xint0x80_syscall+0x20
--- syscall (304, FreeBSD ELF32, kldload), eip = 0x33ccbf9b, esp = 0xbfbfecdc, ebp = 0xbfbfed08 ---
Uptime: 6m27s
Physical memory: 499 MB
Dumping 37 MB: 22 6

_ [FreeBSD]USB Mass Strage Driverも壊れてる？

umass経由な USB CD-ROMや USB Memoryの camデバイスのattach辺りで panicするようだ...Note PC的にはかなり深刻だよね

_ [FreeBSD]Firewire生きてる！！

Firewire接続のHDDは問題なく繋がるようなので、cam回りが完全に壊れている 分けでは無さそう...USB2とかATAPI-CAM再実装まわりでenbugしたのかな？

_ [SAD]コードの整理

ごそごそとコードを整理中だが、可読性や インターフェースを明確にするために

• implicit real宣言を全廃する
• -fimplicit-noneでコンパイル可能にする(explicitに型宣言する)
• 仮引数宣言に、intent属性を付ける

する必要があると思う。

というか、Fortranにも implicitな型宣言や、戻り値の型宣言のみで interface宣言が無いfunction/subroutine呼び出しを禁止してほしい 今日この頃

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

解禁になったので、Arkで一式調達したのだが、 X399M TaichiのソケットにCPUを挿入するとネジ(1)がしまらない事態が発生(ダミー蓋はOK) Orz

ネットでも、一部のSocket TR4でネギが閉まらない不良が報告されていたので、サポートに持ち込んで調査してもらうことに

店側の検証用のCPUでも同じ症状で、別のマザーだと持ち込んだCPUを含めて正常に蓋が閉まるとのことで、マザーボードの初期不良交換となりました

店の人も噂には聞いたが、蓋が閉まらない現物を見たのは始めてだとか

_ [雑記]kblogrdc更新

ここ1週間ぐらい作業しているKEKBLogの読み出し系の更新作業が一段落

• レコード名照合処理の改善(読み出し範囲全域で照合)
  • 記録開始直後の読み出しや、読み出し範囲の途中で記録から除外されているケースをサポート
    • 記録境界での読み出しエラーをさけるために正規表現を使う必要がなくなった
• レコードバッファリング処理の削減 (メモリ使用量の削減・高速化)
• 読み出しレコード毎に時刻処理を独立化
  • 時刻毎にレコードをまとめて出力する機能をオミット(不定長のバッファが必要になるため)
  • timestampの狂ったレコードが記録されていても読み出し終了条件はレコード毎に個別に処理される
    • 頭出し操作に関しては、milestoneのtimestampがアーカイバー側の時計なので、意図通りに切り出せないケースが残る
  • レコード固有のtimestampが単調でないケースは誤作動する
• データ間引き処理の実装(データ出力の最小間隔を設定可能に)
  • 既存のd制御子は指定間隔へのリサンプリングなのでデータ量が増えるケースがある (多分、r制御子に改名すべき)
• 内部ルーチンの整理・統合
  • 出力フォーマッタの整理・分離
  • kblogrdcとclient専用コードとの共通部の共有化
  • デバック出力の整理
• free形式のtimestampをISO8601ベースのCCYY-mm-ddTHH:MM:SS.SSに変更 (自然に昇順ソート可能にするため)
• kblogrdd通信プロトコルの改訂・エラー検出・レポートの強化

但し、kblogrdd通信プロトコルが変更となるため、どこかでタイミングを合わせて入れ替える必要あり

_ [Ryzen]X670マザー

Ryzen 7000が 9/27に解禁になるが、M-ATXマザーの選択子の無さが… Orz

今のところ、ASUSしかないが、拡張スロット構成が x16 + x1なので、GPU + 25/10Gbps NICな構成を考えると絶望しかない

公開されている写真を見る限り x1側は、エッジフリーだが、マザーボードカバーのデザイン的に x16のカードが挿せるか微妙に見える… (エッジフリーにしている以上、カバーが一部外れる等の対応を期待したいが)

25Gbps NIC(ConnectX 4)などを考えると Gen4 x1は帯域不足なので、NICが x16側を消費する構成しか考えらない

M.2 x4を一つ犠牲にして x4スロットを一つ増やして欲しいところである

_ [雑記]NTP with GPS/1PPS

どうやら1PPSロック時の安定度は、GPS受信機依存性よりもホスト依存性が高いようなので、手持ちの機材で調べてみた

(*1) 概30分周期の明確なスパイクが観測される

変なスパイクが出なければ、Ryzen 5950Xの圧勝なのですが、実用上は Intel N305とかRaspberry Pi4などの小型マシンが優位の模様

_ [Ryzen][FreeBSD]Ryzen 7950X vs 9950X

ほぼ同一構成での比較 (厳密には、CPUクーラー構成が異なる)

• ASRock B650M PG Riptide WiFi (v3.60 AGESA 1.2.0.0a Patch A)
  • SMT ON
  • PBO 85℃制限 (Preset menuから選択)
• Crucial CP2K48G56C46U5 (DDR5-5600)

buildworld + buildkernelのlaptime

• 負荷の並列度に対する振る舞いは概ね一緒
  • SMT使用で15〜16%程度のコンパイル時間短縮になっている (但し、平均タスク並列度は32に達してない模様)
  • cpuset(1)で16C固定動作したスコアは、SMT OFF時の測定とほぼ一緒 (誤差1%未満)
  • 16並列時にcpuset(1)で16C固定にしない場合は、4〜5%のオーバーヘッドを生じている
    • おそらく同一コアのSMT threadにタスクが放り込まれる (Kernel Schedulerの改良が望まれる)
• 7950Xに対する9950Xのbuildworld+buildkernel性能は17%増し
  • AMD公式ベンチ等から予測される範囲
• Curve Optimizerへの特性はかなり違う
  • 9950Xでは、BIOS Preset Menuの PBO/85℃/-30mVは安定、PBO/85℃/-40mVは不安定 (memtest86完走・buildworldはハングアップする)
  • 7950Xでは、BIOS Preset Menuの PBO/85℃は安定、PBO/85℃/-20mVは不安定 (buildworldはリブートする)
    • メモリ動作がCPU定格のDDR5-5200ではなくDDR5-5600なので足回りの安定度の問題か？DDR5-5200での検証も行ったが、Preset MenuのPBO/85℃/-20mVはbuildworld負荷でrebootする
      • Curve Optimizerを個別設定で、All Cores Negative 10unitはbuildworld stress test 7時間をパス・15unitだと1st lapでrebootした
      • 国内解禁日に入手した個体だが、単純に耐性が低いだけか？ (補正を入れないPBO動作のみなら安定している)