ドラッグレースの4分の1マイル走や陸上競技の1マイル走は、競技におけるスピードを測るベンチマークです。1マイルを4分以内で走れるのは神業と言えるでしょう。
しかし、もし時計が故障し、実時間の1秒ごとに時計の0.5秒しか加算されていなかったらどうなるでしょうか？そうなると、平均的な人の8分マイルのタイムが、神のような4分台にまで達してしまうことになります。残念ながら、これはPCベンチマークではすでに発生しており、「RTCバグ」と呼ばれるシステムの時間認識を変化させる問題によって、かなり前から発生しています。
ベンチマークは、異なるPCプラットフォームの同一負荷時におけるパフォーマンスを測定するために使用します。科学的に言えば、ベンチマークのワークロードは一定です。3Dベンチマークの結果は1秒あたりのフレーム数で測定されますが、SuperPiなどのアプリケーションはワークロードの完了にかかる時間を秒単位で測定します。どちらのベンチマークの結果も、正確な時間測定に完全に依存しています。1秒が実時間で1秒ではなくなると、これらの結果を比較できなくなります。したがって、ベンチマークは無効となり、スコアは不正確になります。
PCベンチマークにおける時間計測の問題は今に始まったことではなく、ベンチマークにおける時間の認識を歪めるような不正行為に対しては常に闘争が行われてきました。しかし、Windows 8でRTCバグが発生したことで事態は手に負えなくなりました。Microsoftがシステムの基本クロックを変更した結果、複数のOSタイマーが誤動作し、システムのパフォーマンスと合致しない不正確な結果を報告するようになりました。
その結果、HWBOTは、複数のIntelプラットフォームとほぼすべてのAMDプラットフォームにおいて、Windows 8および10で作成された結果の読み込みを禁止しました。現在でも、リファレンスクロックを変更できるすべてのAMDプラットフォームがこのバグの影響を受ける可能性があります。幸いにもWindows 7は信頼性が維持されていたため、必要に応じてベンチマークテストで新しいバージョンのWindowsを避けるという解決策がありました。
RTCバグの発生から約6年後、AMDのZen 2が発売されましたが、このバグは最新バージョンのWindows 10でも未解決のままです。さらに悪いことに、Windows 7へのフォールバックはもはや不可能です。パフォーマンスと安定性の面で現在混乱状態にあり、サポート終了が近づくにつれて改善の見込みはありません。その結果、HWBOTはSuperPi、wPrime、Cinebench、Geekbenchなど、すべての「安全でない」ベンチマークにおいて、すべてのRyzen 3000 CPUのポイントを無効化せざるを得ませんでした。
Tom's Hardware の最高のニュースと詳細なレビューをあなたの受信箱に直接お届けします。
最大のオーバークロック データベースである HWBOT.org は、当初からこれを真剣に受け止めており、データベースの神聖さが不正行為 (ユーザーが知っているか、過失によるかに関係なく) によって汚染されることを防ぐために、許可される内容について明確な概要を設けています。
Windows システムタイマーの問題は複雑なため、マティアス・ズロネク氏に詳細を伺いました。ズロネク氏は優秀なソフトウェアエンジニアであり、オーバークロッカーでもあります。彼は、RTC バグがあっても、競技レベルのオーバークロッカーがベンチマークの精度を検証できるツールを開発しました。
RTCバグとは、システムのベースクロック（リファレンスクロック）をオーバークロックまたはアンダークロックすることで、ベンチマークで測定される時間を変化させるタイマーの欠陥です。「例えば、i7-4770Kを104MHzのベースクロックでWindows 10で起動し、お気に入りのOCツールで98MHzに下げてベンチマークを実行したとします。実行時間は6%短くなります。逆の場合も同様です。98MHzで起動し、104MHzにオーバークロックすると、時間が6%長くなり、オーバークロックなしの場合よりも悪い結果になる可能性があります」とZronek氏は説明しました。
これらの不正確な時間計測は、HWBotがベンチマーク提出の検証に要求する標準スクリーンショットには記録されません。修正がないため、HWBotはバグの影響を受ける可能性のあるWindows 8および10のすべての結果を禁止しました。つまり、例えばベースクロックを調整していなくても、Ryzen 9 3900XのCinebench結果を提出することはできません。
残念ながら、RTC バグに関する公式情報は存在しないため、Zronek 氏はこの問題の調査を始めました。
「まず基本的なことから始めましょう。カーネルはティックを刻みます」とズロネック氏は説明します。「CPUによってトリガーされるシステムクロック割り込みがあり、OSは定期的に起動して、処理すべきタスクがあるかどうかを確認します。これは通常1秒間に64回発生し、各ティック間隔は15.6250ミリ秒です。ティックが発生すると、内部のティックカウンターが前回の起動以降のティック数を累積します。一部のベンチマークでは、このカーネルティックカウントを使用して時間を計測します。特に古いベンチマークではそうです。カーネルティックは、タスクバーのシステム時刻の更新にも使用されます。」
しかし、オペレーティングシステムはシステムクロック割り込みに別のタイムソースを自由に選択できます。以前は、プログラマブルインターバルタイマー（PIT）を使用してウェイクアップを実行していました。また、リアルタイムクロック（RTC）も、定期的な割り込みを発生させるように設定できます。どちらも独自の水晶発振器を備えており、CPUやバス周波数とは独立しています。
Windows 8では、最先端の「ティックレス」カーネル、あるいはMicrosoftが呼ぶところの「ダイナミックティック」が導入されました。システムクロック割り込みは、固定間隔で定期的にウェイクアップを生成するのではなく、スケジューリング作業がある場合にのみ割り込みが発行されます。これは、例えばスレッドが5秒間スリープし、作業を続行するために再びウェイクアップする必要がある場合などに発生します。こうした長時間のアイドル時間中、CPUはより深いCステートを維持して電力を節約できます。これは特に、Windows 8が初めてターゲットとしたタブレットなどの低消費電力デバイスに当てはまります」とズロネック氏は続けました。
ティックレスカーネルへの移行に伴い、Microsoftはシステムクロック割り込みの優先タイムソースも密かに変更しました。LAPICタイマーが登場します。これはCPU内部に搭載され、システムのバス周波数によって駆動されるため、直接接続される、広く普及している高解像度タイマーです。MicrosoftがPIT/RTC（Windows 7以前）からLAPICタイマー（Windows 8 + 10）への切り替えを決定した理由は推測するしかありません。私の推測では、動的ウェイクアップコールで発生する可能性のある追加の遅延を削減するために、より細分化されたタイマーを使用する必要があったと考えられます。ちなみに、「動的ティック」を無効にするには、管理者特権のコマンドラインウィンドウで次のコマンドを実行します：'bcdedit /set disabledynamictick yes'。
ズロネック氏は、「RTC バグ」という用語は、この問題を説明するために広く使用されているものの、完全に正確ではないと述べています。
Zronek氏は、ドライバを使ってタイミングの問題を測定する独自のツールを作成し、上の画像に示すように、リアルタイムクロックは実際には問題とは何の関係もないことを発見しました。Zronek氏は、この問題はLAPICが時間測定にバスに依存していることに起因しているため、より正確な用語は「LAPICタイマーバグ」だと考えています。
根本的には、このバグは、呼び方は何であれ、ベース周波数の変更によって引き起こされます。影響を受けるシステムのベンチマーク結果は、ベース周波数を変更しない限り利用可能ですが、Tom's Hardwareのレビューではベース周波数を変更していません。注目すべきは、結果に大きな歪みは生じないかもしれませんが、多くのマザーボードはベース周波数が不安定で、上下両方向に毎秒数マイクロ秒変動する可能性があることです。これは測定可能ですが、テスト結果に大きな影響を与えません。
WindowsでHPET（高精度イベントタイマー）を有効にすることも、この問題に対処する有効な解決策の一つですが、注意点があります。このタイマーはWindows 8と10のバグを修正しますが、管理者特権のコマンドプロンプトでコマンド（「bcdedit /set useplatformclock yes」）を入力する手動操作と、再起動が必要です。
Zronek氏は、HPETにはさらに深刻な問題があると説明しています。「HPETを強制することの最大の問題は、システム全体への影響です。先ほど、OSの定期的なウェイクアップであるシステムクロック割り込みについて説明しました。HPETを有効にすると、割り込みのタイムソースがHPETに切り替わります。つまり、カーネルのティックと、ティックに依存するすべての時間管理用API関数は、HPETに依存することになります。これは良いことです。問題が解決するからです。そうでしょう？」
残念ながら、これは古い世代のCPUにのみ当てはまります。コア数の多い最新のCPUでは、HPETを有効にするとパフォーマンスに深刻な影響が出ます。HPETは非常に高精度なタイマーですが、チップセット上に常駐するためアクセスが遅くなります。システム内のすべてのタイミング操作にHPETを使用すると、CPUのボトルネックとなり、FPSが低下したり、Windows UIの表示がカクツキになったりすることもあります。この異常はKaby Lake XとSkylake Xで特に顕著で、私が最初にこの異常を検出しました。しかし、RyzenとThreadripperにも悪影響があります。私はこれを「HPETバグ」と呼んでいます（あまり一般的ではありませんが）。タイマー設定がシステムに与える影響をテストするための「TimerBench」という小さなベンチマークアプリを紹介した記事も執筆しました。
以下のビデオでは、ゲーム中に HPET が及ぼす影響をリアルタイムで確認できます。
この問題に対処するため、Zronek氏はベンチマーク結果の検証における新たな基準を定義できる可能性があると考える独自のユーティリティを開発しました。Zronek氏は、このユーティリティはベンダーが製品の宣伝に使用するベンチマーク実行や、レビュー担当者がテストに使用するベンチマーク実行にも広く適用できると考えています。
「これはBenchMateという名前で、その主な目的はベンチマークを再び手軽に行えるようにすることです」とズロネック氏は述べた。「ダウンロードして起動し、好きなベンチマークを実行するだけで、必要なシステムデータを含む結果が自動的に取得されます。ボタンをクリックするだけでスクリーンショットを保存し、HWBOTにデータを送信できます。Windows 7、8、10、そして最新・旧型のハードウェアで動作し、サポートされているすべてのベンチマークを同じ基準で検証します。信頼性の高い時間測定を行い、不正行為を防ぎ、比較可能な結果、ひいては競争力のあるベンチマークに必要なすべてのルールを自動的に適用します。」
Zronek氏によると、BenchMateは必要に応じてアップデートでき、Windowsシステムタイマーの将来的な変更や新たなセキュリティ脆弱性の発生にも対応できるとのことです。このソフトウェアは無料で、現在は競技的なオーバークロッカー向けのHWBotテストへの参加を目的としていますが、Zronek氏によると、より多くのベンチマークを組み込んだ新バージョンが登場する可能性があるとのことです。
最後に
ベンチマーク検証はオーバークロッカーだけが重要だと考えるかもしれませんが、そうではありません。企業はハードウェアのプロモーションにベンチマークを頻繁に利用し、一部のレビュアーは分析の多くをベンチマーク結果に基づいて行っています。また、世界中の人々がベンチマークを使ってシステムを比較しています。ベンチマーク結果はハードウェアの真のポテンシャルを示すのに非常に役立つため、そうすべきです。
しかし、これはベンチマークがシステムのパフォーマンスをすべてのプラットフォームとOSバージョンにわたって確実に測定できる場合にのみ機能します。なぜベンダー、特にAMDとMicrosoftがこれを真剣に受け止めないのか、私には全く理解できません。
しかし、AMDプロセッサとWindows 10を使っていても、正確な結果を得る方法はあります。AMDの結果をHWBotに送信できる唯一の方法であるBenchMateを使うのも良いでしょう。ただし、HWBotで優位に立とうとしていないのであれば、そもそもベースクロック周波数を変更しないのも一つの方法です。
詳細: 最高のCPU
詳細: IntelとAMDのプロセッサ階層
詳細: すべてのCPUコンテンツ
オーバークロッカーとして世界チャンピオンに輝き、速度記録を追跡するサイトHWBotで頻繁にトップに立つアレンは、CPUを限界まで追い込むためならどんなことでもする。彼は、ハードコアで限界まで追い込むオーバークロッカーの視点から、最新プロセッサに関する洞察をTom's Hardwareの読者に共有する。
