# 意見交換 2023/11/10

## 阿部

- NFSrootはメモリを食う
- RasPiはメモリが弱い
- NFSはパフォーマンスが出ない
- NFSサーバの負荷デカすぎ
- 帯域幅めっちゃ必要
- Kernelの調整が必要
- 自動インストールにする
- パーティションテーブルの読み書き
- busyboxにaptだけ入ってるやつ
- aptで必要なKernelだけ入れる
- 必要最小限にしてボトルネックを下げる
- 評価をどこでやるか
- ハイパフォーマンス寄りにすると困る
- KernelとかをReadOnlyでマウントする
- /homeだけをWritableでマウントする
- これOverlayFS使うとかどうなんだろ（By かふぇぱ）
- SDカードをユーザデータの保存用に使うと良い
- RasPiのコントロール
- PoESWを介す
- 中央コントローラを介す

## 大竹

- 瞬間によってCPU使用率が100％になる時間が変わる
- 式の作り方を変えたほうがよい
- 増加量の取り方を考えた方がいい
- CPUがマルチコアの場合の計算方法
- プログラムがCPUを使用するのが下手くそなのでマルチコア使用するとうまく割り振れない
- マルチコアのときの計算方法を考えた方がいい
- メモリも見た方がいい
- CPUは足りなくなってもアプリケーションは動く
- 時間がかかるだけで完全に止まることはない
- メモリが足りなくなるとKernelにOOM killされる
- CPUよりもメモリを重点的にやったほうがいい
- WebサーバはOSのリソースをまんべんなく使うので変えなくていい
- CPUの使用率は直線的に変化しない

## 大宮

- 冗長構成取ればよくね？
- ダイナミックルーティング使うと解決してしまう
- 単一障害点が障害発生したら終わり
- 復旧できるネットワークの前提を考える
- 完全復旧が必要化どうか
- 復旧できない場合→どういうネットワークを組めば復旧できるかを提案する
- インターネットへの出口が死んだときにどうにかする
- オペレーティングミスの方に全振りする
- コンフィグミスをどうにかする
- ハードウェアはやることが多すぎ
- ハードウェアは難しすぎる
- ソフトウェアルータで自身のコピーを作り出してトラフィックを流す

## 奥田

- テストベッド間でのリソースの融通
- リソースの種類とか量とかが違う
- ハードウェアの仕組みが違う
- 共通の仕組みとか言語が違うのでそれらを変換する
- deterlabとstarbed間で同じようなことしてる
- 出せるもの出せないものの成約をどうやって記述するか
- 別れている意味がなくなるかも
- この研究をやる意義とか意味とか
- 異種性とか
- 権利権限の設定
- コマンドの扱い
- できることできないことが所によって違う
- できることによってリソースの割り当てを変えるのは難しい
- 適切な割り当てが難しい
- 難しいところを明確にしてどうやって解決するかを示す
- 今回作るのはこれでいい
- 人間が勝手にいろいろ設定していい
- リソースの定義がクラスタ間で違う
- DBのレプリケーションすれば借用モジュールは予約だけすればいい
- 全体で同じデータを持つ
- 前提の条件・制約の設定からその解決法
- これやらないと意味とか意義とかがわからなくなる
- 落とし所をどこにするか
- 作った上で制約を作るのもあり
- 各クラスタは異質なものがいい
- 同じもの複数だと最悪手動でいい
- バッチを想定
- バッチが終わればリソースは開放
- バッチをより早く、より高密度でやる
- ハイパフォーマンス寄りになってくるかも
- deterlabはこれ
- starbedは違うのでうまく行かない
- シミュレーションでできるかも