UM2019アンケート結果

TACパート全回答編

CfCA TAC 委員長 細川隆史集計 滝脇知也

ご協力ありがとうございました！

• 156人の方からご回答をいただきました．

• 厚く御礼申し上げます．

57%

11%

8%

8%

12%

4%

2019

2019

640コア以下の使用が多い。160コア以下もある。

カテゴリごとの良く使うコア数

0

20

40

60

80

100

120

XC-A XC-B+ XC-B XC-MD XC-trial CfCA内部

40以下 160以下 320以下 640以下 1280以下 2580以下 2580超

2580

1280

640

1280

640

320

160

640

320

160

640

320160

40 40

160

40320

640

1280

%

%

%

%

%

考察

640コア以下はどのカテゴリでも使われている。

カテゴリBは640コアが顕著

カテゴリB+320-1280コア程度が顕著

カテゴリAは640-2580コア程度が顕著

カテゴリBとAでも、せいぜい4倍程度の資源の差

それほど選択と集中はされておらず、均等に資源を配布している。

40コア• 同時に8つの計算を行っているから。

• コード由来

• 必要な計算規模由来

• 計算は重くないので、少ないコアで計算な順番がスムーズに回るため

• コード由来

• XC-Trialであることに加えて、コードの並列度が低いため

• 必要な計算規模由来

１６０コア• スケーリングがそこまでよくないので、計算の流れやすさを優先してbulk-bを複数流すことが多い。• 必要な計算規模由来• 必要な計算規模由来• 必要な計算規模由来• 流れやすさ、コードの並列効率• 計算の性質上• 計算の性質上ノードを増やしすぎると効率が落ちるのと、バルクで数多く流す必要があるから。• 必要な計算規模由来• 必要な計算規模• bulk-bで最大コア数である2ノード80コアでジョブを複数流すのが最も効率がよいため。• 必要な計算規模由来、計算の流れやすさ由来。• 必要な計算規模由来• 行っている計算がモンテカルロ的な計算なため多ければ多い程よいから。• 必要な計算規模由来• 計算の規模由来と計算の流れやすさ• 計算の流れやすさ• 必要な計算規模(1runあたり)由来• XC-trailのコア数が限られているのです。• bulk-bでパラメータスタディーを多く行なっているため• 計算の流れやすさです。

３２０コア• bulk-bp が最大8ノードのためです。

• 必要な計算規模

• 計算の流れやすさ

• 計算の流れやすさと、現在は試験的な計算で、ランの数を多めにして、統計的な結果をみたいので。

• 必要な計算規模由来

• 計算規模と計算の流れやすさ

• 必要な計算規模とジョブ実行までの時間を考慮して

• bulkで走らせられるコア数が最大320のため。それ以上だと同時に走らせにくくなる。

• bulk-bpキューの最大サイズだから。

６４０コア• 必要な計算規模由来• コード由来• コード由来でかつ長時間計算を行うため• 必要な計算規模由来• 1000コア以上の計算は流れにくい印象があるため• 計算規模• 必要な計算規模由来• 必要な計算規模由来• 計算規模とコードが完全並列性を備えているので、XC-Bの最大コア数を使っている。• 計算規模、メモリ。• 必要な計算規模に由来• ベンチマークを取るのに使える最大数• 必要な計算規模由来• 計算コードの特性上、512コアの次は4096コアになってしまい、それだと流れないであろうというのが大きな理由。こちらの現状は大きな計算を一モデルよ

りも、中規模を複数投げるのが研究の成果につながるから。• 必要な計算規模• カテゴリの上限• 割当範囲で最も高速に計算できる• カテゴリ最大ノード数(コア数)で利用するため• 流れやすさ由来• high resolution の計算ではこの程度必要。• 使える上限だから• もっと多くのcoreを使いたいが、これ以上多いと、なかなか計算が走らない。• 400コアが使用可能な最大コア数なので、計算規模の関係上それを使っています。• カテゴリの最大値• もっと使いたいがXC-Bで使える最大のノード数だから。• XC-Bカテゴリで使える最大コア数を使っています。• コードの並列化効率由来• 必要な計算規模由来• 使用可能な計算規模の上限から• 利用カテゴリの中で、自身のコードの設計上で利用できる最大のコア数なので。• コードの都合• 必要な計算規模由来• 必要な計算規模由来• 必要な計算規模由来• 必要な計算資源の最低限のノード数のため。• 必要な計算規模由来/計算の流れやすさ由来• 現実的な時間内に計算を終えるために必要な並列数• 必要な計算規模由来• それがxc-Bカテゴリの最大値だから

１２８０コア• 現在の研究に必要なシミュレーションの規模とXC50上での走りやすさを最適化すると32ノード程

度が最適である。

• 必要な計算規模由来

• 計算の流れやすさ、コードのスケーラビリティから最も効率良いため。

• 計算規模の都合

• メモリがリミットしています。並列化効率の観点からも、これ以上の大きなコア数で利用する必要性はありません。

• 経過時間制限が同じなのでなるべく強スケールしようとしてしまう

• カテゴリの最大資源量だから

• 計算の流れやすさ

• 必要な計算規模と計算の流れやすさの兼ね合い

• 計算の流れやすさ

コード由来。

ジョブがスムーズに流れる、計算がスケールする、計算時間などを勘案した総合的な理由必要な計算規模由来このコア数でも本計算には数ヶ月かかるが，これ以上の規模にしても流れないから．計算の流れやすさを考慮した結果（本当はもっと大きな計算を投げたい）計算が数週間で終わるために必要な計算規模由来必要な計算規模由来

256０コア

23%

64%

12%

およそ９割の方は許容範囲内と考えているようだ2018と分布はほとんど変わらない。

2019

カテゴリ別待ち時間

0

20

40

60

80

100

120

XC-A XC-B+ XC-B XC-MD XC-trial

長すぎ だいぶ待つ 許容範囲内 快適

待ち時間に対する感覚は

カテゴリによらず似たようなもの。

だいぶ待たされる• ...こともあるのは仕方ないですね。学会前とか。

• 60ノードのジョブが、１週間に2回くらいしか走らない。

• 時間によっては混んでいるように思う

• 混雑時は8時間以上待たされる

• 正直，時期によります．

• 2000コアを超えると流れにくい（実行効率が1000コアよりも落ちる）印象です。bulkキューでの500コア程度の計算も実質１つしか投げられません。

• bulkキューでの待ち時間は少ないが、largeキューでは1000コア程度以上は

かなり待たされる。これでは大規模計算ができず、実質ユーザの計算規模はbulkキューの大きさで決まっていると思う。

許容範囲内• たいてい6時間以内に走り、70%以上の稼働率なので許容範囲内である。• 待ち時間が長く感じるときもありますが、個人的には許容範囲です。

• 時期にもよるので一概には言えないが、一回の計算時間の半分以上の待ち時間はほとんどないから

• なかなかジョブは実行されないがやむを得ない。幅広いサポートの裏返し。• 概ね許容範囲ですが、本年度はbulkキューでの待ち時間が気になりました。

• 時期によっては待たされることもあるが、基本的には解析する時間を考えると許容できる。

• 160コアくらいまでは、すぐに流れて欲しいが、タイミングによっては待たされることもある。

• 2ノードbulk-bの計算での待ち時間はほとんどなく快適であるが、ノード数が大きくなるにつれて、待ち時間が長くなる。具体的に、large-bで１３ノードで１日程度。

• 概ねポストプロセスやデータ転送のコストを考えると、現在の待ち時間＋計算時間は理想に近いです。

• 1ランが24hになったので、待ち時間が長いと感じられる時には寝ていられる。• 時々、待ち時間が長い。• 待ち時間が理由で深刻に困ったことがないので。• 待たされることは度々あるが、長くても数日程度であるので、許容範囲内と考えている。• 学会前は混んでいる印象だが、千コア程度ならあまりストレスなく流れている印象。• 空いている時もあるが、混んでいる時は一日以上ジョブが流れない。• 1日1ランくらい走るので。• ここ1,2ヶ月は待ち時間が増えたように感じていますが、良好と思います。

快適

• bulk-bで流した場合、待ち時間も含めて次の日に終わっていれば十分であることが多い。

• 特に不満はありません。

• 自分が使用しているコア数の範囲ではそれほど待ち時間はない。

• 今まで問題に思ったことがないため。

• bulkであればかなり快適と言えると思います．

2019

60%

16%

23%

1%

カテゴリ別キュー構成満足度

どのカテゴリでも普通以上が優勢。

XC-A, XC-MD, trialで普通がやや多いか。

0

20

40

60

80

100

120

XC-A XC-B+ XC-B XC-MD XC-trial大変不満足 不満足 普通 概ね満足 大変満足

大変満足• XC-Trialにはlargeしかなく、実行時間もだいぶ短いため不満はありません。

• 今の状態でbulkキューがよく流れているように感じる。

• 困ったことがほとんどないから

• 今まで問題に思ったことがないため。

• bulk-bが使いやすい。

• 自分の計算要求に特に噛み合わないわけではないので、大変満足している

• 主要な計算を large キューに、それ以外の計算を bluk キューにジョブを投げて、ユーザが優先度をつけられるから。

• 特に不満を感じたことはないため。

概ね満足• 計算を安定に走らせるうえでこれでいいと考える。• 特に不自由していないため。• 上の質問と同様、私が運用する上で不満に感じることは少ないです。• 申請カテゴリの制限一杯を利用しているが、特に不便を感じない。• 大きなノード数のジョブが実行できやすいよう、large bulk でノード数の下限を設定して、低いノード数

の継続時間を4-6時間以下になるようにしてほしい。• 特に不満に思うことはないです。• おこないたい計算ができているため• ジョブ投入後，おおよそのジョブ開始時間が数分後なのか1時間後なのか見積もられるとありがたい• 自分の研究に必要な千コア程度のジョブがあまりストレスなく流れているから。• bulkの12時間上限は少し短い気がしますが，待ち時間の短さを考えると納得できる時間だと思います．• largeキューをよく使うので、largeキューが優先なのはありがたい。• 「largeキューの優先度はbulkキューより高く設定されております。」この情報を初めて知った• 一人当たりに許される待機ジョブ数 (queue に入れられるジョブ数) を増やしてほしい (特にテスト計算

を多数実行したい時などに必要)• largeキューを複数走らせることが難しいことを除けば満足しています。• 主に使う64コアのジョブで、1日待つことはまず無いため概ね満足しておりま

普通• Bulkキューの優先度を上げていただきたいです。• XC30のときのbulk-Bで160コア×8時間使えるのがとてもよかったです．

4時間だとすこし短い気がします．• bulkでもう少し大きいものが設定できると良い。1000コアまではいかな

いが大きめの計算を短時間複数流したい時に、largeは常に混みあっているため、基本的に一つしか流れないので。

• キュー毎に制限時間が違ったほうがよいのでは．4ノードから8ノードを優先すると効率は良くなりそう．

• large-bでは最大同時実行ジョブ数10と利用手引きにあったが、ほぼ1ジョブづつ順番で実行されている点が不満。

• どうやっても誰かの不満は出そう．• XC-BとXC-B+の使えるノード数の差が大きすぎる。XC-B+ぐらいを使い

たいのにXC-Aに申請して落ちないといけないというのは申請しづらい。

• XC-Trialにはlargeしかなく、実行時間もだいぶ短いため• largeキューではほとんどの場合、1ジョブずつしか実行されず、1000コアを超えるような大規模計

算だと待ち時間が長くなる。bulkキューであればそこそこな規模で通常３ジョブまで同時実行され、待ち時間もほとんどない。ゆえにbulkキューの最大サイズで計算を実行することがほとんどである。他のユーザも大体そうしていると仮定すると、bulkキューが優遇されすぎているために、largeキューが走らない状況なのではないかと思う。

大変不満足

62%

5%

35%

2018 2019

問題なし 67% 62%

問題あり 11% 5%

わからない 22% 35%

昨年度に比べて問題ありという人がだいぶ減った。わからないという方が多い。

カテゴリ別審査の感じ方

あまりカテゴリによらない。

0

20

40

60

80

100

120

XC-A XC-B+ XC-B XC-MD XC-trial

わからない 問題あり 問題なし

問題あり• 審査結果の理由やその程度が分かりにくい。

• 審査員を公開していないので、審査が不透明である。どのような人が審査しているか知ることで、申請書の内容が変わるので、過去の審査員を公表すべき。同じ人が審査し続けるのを避けることもできる。

• はやりすたりがあるのはわかるが、一定の課題(相対論とか)に大規模 Que カテゴリーが割り振られているように感じる

• 学生優遇されすぎ。

• レビュアーのコメントが短すぎる。きちんと審査されているのか疑問。また、人数や分野などのレビュアー情報もある程度公表すべき。

わからない• 自分はカテゴリ B+ と B を行ったり来たりしているが、審査に通るときと通らないときの違いがい

まいちわかっていないです。

• 年度に依りますが、審査員のコメントや評価にばらつきがあるのではないかと感じることもあります。

• 不採択になった事が無いが、今後さらに大規模計算を希望する時にはどうなるかわからない。• どのような申請が審査を受かって、どのような申請が審査を落とされるか知らないので。

• 審査をやった経験からすると分野外のものを公平に審査するのは難しいが，他に良い方法も思いつきません．

• 審査に関わっておらず、他の人の申請書を見た事がないので判断しかねます。• コメントが開示されるところは良いと思います。

問題なし

• 面白いサイエンスケースに大きな計算機資源が割り振られており、適切でないと考える理由はない。

• 審査員のコメントが納得の行くものであるから

• 審査員からのコメントを閲覧できるのは良いです。科学的成果よりコードの性能が重視される傾向にあるのは改善していただきたいです。

• 審査結果に不満はないため。• 審査方法がフェアであると思う。

• 特定のユーザが上位カテゴリに固定しないような仕組みがあっても良いかもしれない。チャレンジ枠など？

• 内容を読んで理解したうえでコメントしている印象を持ったから。

• 去年のユーザーズミーティングに参加したが、皆さん積極的に研究している印象だったため。

• 現状で満足できるカテゴリをいただけています。• コメントが的確であったと感じました。

XC50の運用に関する改善案• XC50の運用に関して改善案の提案をお願いします。何をしたら（あるいはしなかったら）運用ははもっと良くなると思いますか？• Open-Ended Response• ①京都大学基礎物理学研究所のXC40のようにジョブの待ち時間(予想開始時刻)が表示できるとより良い。 ②60日でデータを消去する必要性は理解できるが、11月の削除開始時に通告から

実際の削除まで1日しかないというのは問題だと思う。実際に私も多くのシミュレーションデータが消された。 充分に入念なアナウンスを流してから削除を開始すべきであったと考える。• 運用全般に全く不満はありません。ただカテゴリ B の work 以下のファイルシステムの容量（上限10TB）が増えれば、もう少し使い勝手がよくなる気はします。• testキューの優先度を上げてほしい• 特になし• 柔軟な運用を続けていただければと思います．• XC-Aの枠は必要か疑問？利用可能ノードをフルで使った計算は現実的な待ち時間で実行されるのだろうか？現在のB+をAの枠にしてもいいと思う。• 小さいジョブでも重要な計算ができるため、bulkキューで待ち時間なく計算できるようにしていただきたいです。• 現状では特にない。• キューの構成について、UMより前にアンケートで出てきた意見を基に問題提起をして、当日に意見を求めた方が良いと思う。当日いきなり意見を求められても議論しにくい。• メンテナンス、不具合が多いような気がしますが、どうしようも無い気もします。• 使っていない• 現行の運用体制を大きく変える必要を感じません。何かに特化した大きな改革をするのではなく、今のやり方を是非継続してください。• ジョブあたりの経過時間（walltime）上限をもっと長くしてほしい。 1コア当たりのメモリが他のシステムに比べて大きい（9.6ＧＢ/コア）ので、メモリ制限ぎりぎりのジョブを流すと、何十回もrestart

をかける必要があり、面倒である。• 特に不満は無い。• pdf サイト等において利用情報が違うことがあるため、サイトの記述を極力やめてpdf等で統一したほうが良いと感じた。• bulk-b の1度の計算で使えるコア数を増やして欲しい。 同時に流せる job の数は減らしても構わない。• ノードを増やす• データ転送に少し時間がかかるので、うまいやり方があれば教えてほしい• 計算の待ち時間がどれくらいになるか、大まかにでも知れるととても助かります。• 現状で問題ないかと思う• 本年度からlargeキューのジョブの連続稼働が24時間になったが，一方でジョブ投入後なかなかジョブが流れなくなった．12時間に戻しても良いのではないか？• Que カテゴリーの見直しを強く希望します• 保守のために停止する時間が長い• 運用が十分良いと思います。満足です。

• 特になし。ただ毎年のアンケート結果の公開可能な部分は公開して他の人の意見も見えるようにすると、建設的な意見がより増えると思う。運用結果と利用者の反応の因果関係も分かりやすくなると思う。

• XC50の英語ページを作っていただけると嬉しいです．キュー構成の英語ページだけでもいいです．理由としては，XC50での採択実績をCVに載せたいのですが，XC50は単純にCPUhourではなく，キュー構成なので，「XC-B+に採択された」とCVに書く必要があるわけですが，英語のページがないと海外の人に採択実績の意味が伝わらないからです．

• 利用者に比して十分によく運営していただいているとは理解します• 特にありません。• 特になし• わからない．• 一つのjobの最大時間が24時間になって使いやすくなりました。• 1ノード1コアジョブを多く流してるユーザがいるので、何かしらの制限をしてほしい• 改善案は特に思いつかない．CfCAの方々に感謝する．• 利用申請を年中受け付けること• XC-B+カテゴリに直接申請できる申請枠を設定してほしい• 私はXC-B+のカテゴリをいただいていますが、bulkキューで 最大同時利用可能コア数を1080に増やしてほしいです。 また、単一ジョブ最大コア数を540に増やしてほしいです。• いつもメンテナンスなどありがとうございます。強いて言えばHDD容量が、カテゴリB以下とB+以上で差が大きいので、B以下も増やしていただけるとありがたいと思います。• largeキューがもっと同時実行できるようにしてほしい。bulkキューを優遇しすぎだと思う。• XC-AとXC-B+にリソースが集中しすぎている。もっと広く浅く分け与えも良いのでは。過度な選択と集中はよくないのでは？現状では上位カテゴリの人がほとんど固定されてきているように見え

る。もちろんある程度の集中は必要だが、現状の審査不透明な状態では説得力に欠ける。