Orz日記 by Akio Morita

_ [雑記]CLIEからW-ZERO3[es]へのデータ移植

予定表等の管理をW-ZERO3[es]側に移したいのだが 母艦との同期(バックアップ)をActiveSyncでするには、Outlookを必要... なんかムカツク(Palmの場合、PalmDesktopで完全に閉じるのに...)

PalmとPocketPCをサポートしていたIntelliSyncが使えないかと思い調べたら、 買収されて企業向け製品になっている(50ライセンスからスタートだって)orz

と言うわけで、やむなくOutlook2003を購入する

データの移行手順としては、UX-50付属のIntelliSync Lite for SONY CLIEを インストールして、CLIEのサポートサイトにあるOutlook2003パッチを当てる。 これで、CLIEとHotSyncしてPIMのデータをOutlook2003へ収容する。 最後に、W-ZERO3[es]とActiveSyncでOutlook2003を同期させて終了

_ [KEKB]LER Vertical Emittance

Solenoid付きSuperLERの暫定版Latticeにて、 $\epsilon_y\sim3\mbox{pm}\cdot\mbox{rad}$程度であるが、 これは、IR付近のVertical Bend(BC*)の強さを最大$3\mbox{mrad}$から 最大$1\mbox{mrad}$に制限してもたいして変わらなかった。

KEKB LERの場合

2008/12/14のOpticsで計算すると... $\epsilon_x = 18.0\mbox{nm}\cdot\mbox{rad}$, $\epsilon_y = 1.69\mbox{pm}\cdot\mbox{rad}$

つまり、SuperLERの暫定版Latticeと$\epsilon_y$のオーダーは同じ。

対称点のVertical Chicane(BV[12]P)をOFFにしてみると... $\epsilon_x = 18.0\mbox{nm}\cdot\mbox{rad}$, $\epsilon_y = 2.23\mbox{fm}\cdot\mbox{rad}$

つまり、KEKB LERの場合、Vertical Emittance $\epsilon_y$の主な発生源は、 Vertical Chicane(BV[12]P)である。

SuperKEKB LERの場合

20B-test5c0(BC* limit $1\mbox{mrad}$)で計算すると... $\epsilon_x = 3.28\mbox{nm}\cdot\mbox{rad}$, $\epsilon_y = 3.43\mbox{pm}\cdot\mbox{rad}$

対称点のVertical Chicane(BV[12]P)をOFFにしてみると... $\epsilon_x = 3.29\mbox{nm}\cdot\mbox{rad}$, $\epsilon_y = 762\mbox{fm}\cdot\mbox{rad}$

したがって、Vertical Emittance $\epsilon_y$の約8割が Vertical Chicane(BV[12]P)由来と言うことになる。

よって、Coupling $\kappa$を 0.1%以下に下げることを目標とする場合、 富士直線部のVertical Chicane Magnetを Long Bend化する改造が必要と 思われる。

_ [FreeBSD][Fortran]LLVM/flang on FreeBSD

コンパイラドライバ(devel/llvm50側)をゴソゴソ修正して、-Lオプション無しで、libflangmain, libflang, libflangrti等のランタイムライブラリをリンクできる所まで修正完了

まだ、-Iオプション無しでintrinsic moduleが使えないので、コンパイラドライバもしくはflang1/flang2に埋め込まれているmodule include pathに修正が必要な模様…

tools/clang/lib/Driver/ToolChains/FreeBSD.cppに環境依存のintrinsic module pathを追加するコード(flang1に対して-stdincオプションを設定する)を追加して、追加オプション無しでintrinsic module付きのコードをコンパイル・リンクできる所まで完了

SADのコンパイルを試すのは来年かな？

_ [SAD]jlist掃除 in Cコード

sad_cstrマクロによるstringポインタ参照に書き換える作業を進行中

残っているのは

• src/tfProcess_.c
• src/tfFileIO_.c
• src/tfXlib_.c

_ [SAD]itflist掃除 in Cコード

itflistを使ってon-stack list constructionしているコードを明示的なlistコンテナ割り当てとtfsetlistで書き換える作業を進行中

長大なリストが戻ってくる可能性がある部分では、mstk検査をしていないので stack corruptionの危険が生じている

残っているのは

• src/tfTkInter_.c
• src/tfProcess_.c

_ [SAD]itfmalocp整理

• 唯一の参照元src/tffswake.fが管理するデータ構造と影響範囲の解析完了
• 新しいデータ構造の基本設計完了
• common block上の iwakeoldpと一部関係があるが、こっちはどうする？
  • k64系では、データ構造は廃止されている
  • FFSコマンドに関しては、WAKEコマンドのみSADScriptによる再実装、その他の関連コマンドは廃止されている(要解析)

_ [SAD]helper関数のアイデア

list containerからReal配列ハンドルや Type/Addr配列ハンドルを取り出す操作があるが、内部のデータ構造を隠蔽する為の抽象化helperを用意すべきでは？

検討すべきコーナーケース

• Reals時に、Type/Addr配列ハンドルを要求された際の動作
• NonReals時に、Real配列ハンドルを要求された際の動作

多分、NULLを返すのが妥当？

container生成時だけは、書き込みの為にnon-constである必要があるが、参照用途では、constハンドルを返すべきと考えられる

const/non-constで、helperを分離すべきか？ (C++と異なり、proxy objectによるtype dispatchは行えない)

_ [SAD]implicit宣言コード

includeされているcommon宣言をmoldule化作業で自動検査の障害となるimplicit宣言を含むsrc/inc/*.incの参照

数量的には、TMACRO.incからやっつけるべき？

_ [FreeBSD][Ryzen]Ryzen Threadripper 2950X

基本的な仕込みは終わったので、耐久ストレステストに入ったのだが、未だに安定しない

耐久ストレステストの内容は、最大並列度でのエンドレス buildworld + buildkernel

現在の最長記録は36時間程度で、なぜかハングアップする状況

少なくとも、Ryzen TR1の初期出荷分で発生したSEGV系の不具合ではない

原因の洗い出しと対策のために色々試しているが未だに解決していない Orz

• UEFI firmware ASRockの最新のbeta版(Threadripper回りのCPU firmwareが更新されている為)
• kernel 最新の12-STABLEを使用
• AMD RyzenのErrataリストから 1021, 1033, 1049, 1057, 1091, 1095, 1109に関してはcputontolによるMSRパッチとmachdep syscltによるworkaroundを適用(データーレース・ハグアップ系の対策可能なエラッタ)

この状態でもハングアップするので、さらにSMT回りのデータレース等を疑ってmachdep.hyperthreading_allowed=0にてSMTを殺した状態も試したが、ハングアップする

Tjmaxの超過による熱暴走系を疑って、冷却系の設定を変更してTjを10℃程度低下させたところ、24時間も持たずに30分以内にハングアップした(2回)

• 少なくともCPUの熱暴走によるハングアップではなさそう
  • 冷却強化状態で、Tctl 80℃程度に収まっている
• ブースト機能等が効き易くなってハングアップ頻度が上がったとすると、実行時の競合系のエラッタを踏んでいる？

CPUのエラッタ以外の可能性として疑っているのは

• powerd++による P-stateの動的変更
• NVMeストレージ系の不具合

現在、メインストレージを SATA SSDに切り替えNVMeを切り離した状態かつい、CPU P-stateを固定した状態で、ストレステストを実施中

_ [艦これ]2019冬イベ開始

E-1甲作戦 18:48スタート、20:53 クリア

E-1からラスダン編成が固い Orz