予選第1日に参加していただいた皆様、本日はどうもありがとうございました。誠に申し訳ないのですが、お詫びと、レギュレーション変更のお知らせです。
それは、本日提供していた benchmarker に問題があったことが発覚したためです。
私達運営スタッフの意図としては、 benchmarker による負荷走行は、本来、必ず1分で完了することを想定していました。
今回発覚したのは、benchmarker に大きな数の workload を指定することで高負荷状態を作ると、負荷走行のタイムアウトが機能しなくなるバグでした。 結果として、負荷走行が1分以上走ってしまい、それによって高得点を出せてしまう場合がありました。
いくつかのチームはこのことに気づき、第1日の参加チームのうち数チームは、これを利用した高得点を出していました。
運営スタッフとしては、私達の不備によるバグも競技の要素の一つとして考えており、このことに気づいた上位チームのスコアは尊重したいと考えています。
一方で、このテクニックを使うと、初期の参考実装でも比較的高いスコアを出せてしまうため、 ISUCON という競技本来の面白さを損ねているとも考えています。
そこで運営スタッフでは議論の末、心苦しいですが、以下のようにレギュレーションに変更を加えるという判断をしました。
まず、私達は benchmarker の上記バグを修正し、意図通り1分で負荷走行が完了するように変更します。この修正版を仮に benchmarker v2 と呼び、修正前のものを v1 と呼ぶことにします。
第2日の競技では、この benchmarker v2 を使うことにします。
第1日の参加チームのなかで、AMI審査を経た上位5チームの本戦出場は、上記のテクニックの利用有無にかかわらず、従来通り、お約束します。
第1日の6位以下のチームは、以下の手順によって、採用スコアが決まることとします。
- 審査員は、AMI から EC2 インスタンスを起動し、benchmarker v1 を用いて、最終スコアの再現性を確認します。ここで最終スコアに近い値が再現できなければ、失格となります。これは従来のレギュレーション通りです。
- 次に審査員は benchmarker v2 を用いてスコア計測を行います。このときの起動オプションは、AMI 提出時に指定されたものを用います。**ここで算出されたスコアを採用スコアとします。**これを修正版スコアと呼ぶことにします。
- 審査員は、この修正版スコアが、提出された最終スコアと大きく乖離していても、失格にすることはありません。
この手順で計測された修正版スコアを、最終スコアの代わりに採用します。これは、第1日の参加者と、第2日の参加者の評価基準と揃えるための措置です。
このように修正スコアを算出したうえで、最終的な本選進出のレギュレーションを、以下のように変更します。
- 一般枠
- 予選第1日の最終スコア上位5チーム、予選第2日の最終スコア上位5チームが本選進出
- それ以外のチームについては、予選両日を通して上位13チームが本選進出（※1）
- ただし、第1日のスコアについては修正版スコアを採用し、第2日については最終スコアを採用する。
- 学生枠
- 予選両日を通して上位 5チームが本選進出
- ただし、第1日のスコアについては修正版スコアを採用し、第2日については最終スコアを採用する。
- 予選両日を通して上位 5チームが本選進出
この変更により、第1日のスコアも、第2日のスコアも benchmarker v2 で算出されたものになります（第1日の上位5チームを除く）。
※1 については、これまでのレギュレーションでは上位10チームであったのを上位13チームに増やしています。これは、私達の不手際により、本来、本選に出場できていたかもしれないチームが出場できなくなったという可能性を鑑み、お詫びとして追加いたしました。
この告知は、第1日の参加者のみに向けたものです。第2日の参加者の混乱を防ぐため、第2日の競技が終了するまで、 benchmarker v1 に存在したバグの内容や、スコア算出方法の変更内容について、第2日の参加者に伝えないようにご協力お願いいたします。
私達の不手際により、チューニング競技の面白さや純粋さを損ねてしまったことをお詫び申し上げます。今回の失敗を教訓に、本選では、より公平で、面白い競技を目指して改善を行っていきます。
ふと思ったのですが、この修正版スコアを採用するルールだと、1日目の参加者は予選終了後に手元でスコアを伸ばしてAMIを提出できることになりませんか？
min(最終スコア, 修正版スコア)を採用すると意図したルールになるかと思います。