箱庭時刻同期の実験結果をグラフ化したい

[tmori]

リミット

• 10/9 までできると嬉しい

作業ブランチ

measure ブランチで、ifdefでコンパイル切り替えできるようにする。
作業終わったらREADMEつけてマージする。

作業タスクリスト

• 箱庭時間とアセット時間を、アセット毎にCSVファイルに書き出す機能を追加する #60
• 測定条件を決める（時間精度のバリエーション、多重度のバリエーション、CPUコア数、マシンスペックなど） #64
• 実験用の箱庭アセットを作成する（アセット間の通信はしない） #61
• 測定結果からグラフ化するPythonプログラムを揃える #65
• 測定自動化スクリプトを揃える #66
• 測定結果を評価し、期待通りになっているかチェックする #67
• 測定方法の手順書をREADME化する（第三者チェックができるように） #68

[tmori]

箱庭での時刻同期の定義：箱庭アセットの全ての時間が、最大許容時間範囲内で時間のズレがないこと。

変数の準備

• $C_t$ : 箱庭時間
• $A_t(i)$ : 箱庭アセット $i$ の時間
• $Max\Delta_t$ : 最大許容遅延時間
• $\Delta_t$ : 時間ステップ

関係式の整理

箱庭アセット機能

• $A_t(i) \geq C_t$ ... (Asset.1)
  • 時間を止める
• $A_t(i) \lt C_t$ ... (Asset.2)
  • 時間を $\Delta_t$ だけ進める

箱庭コア機能

• $C_t \geq (\min_{i}(A_t(i)) + Max\Delta_t )$ ... (Core.1)
  • 時間を止める
• $C_t \lt (\min_{i}(A_t(i)) + Max\Delta_t )$ ... (Core.2)
  • 時間を $\Delta_t$ だけ進める

証明の目標

$| A_t(i) - A_t(j) | \leq Max\Delta_t$ ... (A.1)

証明

証明方法

$\max_{j} A_t(j) - \min_{i}A_t(i) \leq Max\Delta_t$ ... (C.1)

を示せば良い。

$\max_{j} A_t(j)$ は、(Asset.1) より、 $C_t$ を超えることはできないので（箱庭アセット時間が止まる）、

$\max_{j} A_t(j) = C_t $

と言える。

$\min_{i} A_t(i)$ は、(Core.1) より、 $C_t - Max\Delta_t$ を下回ることはないので（箱庭時間が止まる）、

$\min_{i} A_t(i) = C_t - Max\Delta_t$

と言える。

よって、(C.1) にそれぞれ代入すると、

$C_t - (C_t - Max\Delta_t ) = Max\Delta_t$

となるので、証明された。

補足

箱庭アセット時間の範囲

$C_t - Max\Delta_t \leq A_t(i) \leq C_t$ ... (B.1)

箱庭時間の範囲

$\min_{j}(A_t(j)) \leq C_t \leq (\min_{j}(A_t(j)) + Max\Delta_t )$ ... (B.2)

[tmori]

この時に、何が言えると良いのか？

1. 箱庭時間同期仕様に対して、箱庭時間と箱庭ア時間の時間差は想定内の挙動を示していること
2. 1 の目的に対して、箱庭のシミュレーション精度変化に対して、想定内の挙動を示しているかどうかを確認する（アセット数=1）
3. 1 の目的に対して、箱庭アセット数を増やすことでシミュレーション精度が妥当な範囲になっているか確認する（アセット数>1）
4. 箱庭時間同期仕様が分散シミュレーションであることから、以下の挙動を示していることを確認する（アセット数=1-10）

• 最大許容遅延時間が小さい
  • 箱庭アセット時間の分散は小さいが、並行動作が難しいので、シミュレーション全体の時間は長くなる
• 最大許容遅延時間が大きい
  • 箱庭アセット時間の分散は大きいが、並行動作できるのでシミュレーション全体の時間は短くなる

[tmori]

測定データ

• 各箱庭アセットの時間
• 箱庭時間

測定方法

箱庭アセットが、箱庭アセット時間をnotify_time で箱庭コア側に通知に来るので、そのタイミングで箱庭アセット時間と箱庭コア時間を記録する。

箱庭アセット毎の計測結果から、時間のズレ幅（箱庭アセット時間ー箱庭コア時間）を計算し、その分散を計測する

これを最大許容遅延時間ごとに集計してグラフ化する。

グラフ

箱庭アセット数＝１

1. 箱庭アセット時間の時系列変化（箱庭時間からの相対時間）
2. 1を２次元平面でグラフ化（右側の絵）

箱庭アセット数＞１

1. 箱庭アセット時間の時系列変化（箱庭時間からの相対時間）を並べて表示
2. （箱庭アセット時間ー箱庭時間）の分散を最大許容遅延時間毎に並べてグラフ化
3. シミュレーション実行時間の平均を最大許容遅延時間毎に並べてグラフ化

[tmori]

期待した結果を簡単に出せそうな箱庭アセット側のプログラムってなんだろう？

• 案1. ビジーループするやつ
• 案2. 適当にスリープするやつ
• 案3. なんだろう？

[mitsut]

案1のアセットだと、アセット数が増えるとシミュレーション時間が増える傾向の結果が出そうですね。

分散しない場合にアセットいくつまでならリアルタイム実行が出きるかが分かる？
(この需要があるのか？)

[tmori]

案1のアセットだと、アセット数が増えるとシミュレーション時間が増える傾向の結果が出そうですね。

分散しない場合にアセットいくつまでならリアルタイム実行が出きるかが分かる？ (この需要があるのか？)

10/9のリミットでやるなら、分散プロセス構成までですね。
そして、CPUコア数でサチル感じでしょうね。

分散ネットワーク構成やるなら腰据えてやらないと難しいっす。それか助っ人がいればできるかも。

[tmori]

今回の実験は、リアル時間との同期は無しで良いだろうか？

[takasehideki]

方針というか私の思ったこととだいたい相違ないように思いました！

箱庭アセット数がどこまでいけるかは興味ありますね．具体的なシミュレーション環境（プロトタイプモデル）ではせいぜい数個ですし，多くても10個くらいまで並列に動作可能なことを示せれば十分だと思いました（もちろん工数との相談はあると思っています）．

[takasehideki]

分散ネットワーク対応は，時刻同期機能の有用性を示すという観点からは，今回はナシで差し支えないと思います．

リアル時間との同期は，通信機構がZenoh対応でReal/Virtual連携可能！という文脈でしたら，気になるところですね．とはいえ今回は先送りでいいかと．

[tmori]

測定モードでの箱庭コア機能ビルド手順

export ENABLE_HAKO_TIME_MEASURE=ON
export ASSET_NUM=10
bash build.bash

インストール手順：

Unity向け

libshakocをコピーする

cp cmake-build/src/hakoc/libshakoc.dylib ../hakoniwa-unity-simasset-plugin/plugin-srcs/Assets/Plugin/Libs/libshakoc.dylib

Python/C言語向け

bash install.bash