Windows 8はCPUクロックの変更がRTCに影響するため、正しいベンチマークが行えない？ 87
ストーリー by hylom
この仕様だと他に影響を受けるアプリもありそうなのだが 部門より
この仕様だと他に影響を受けるアプリもありそうなのだが 部門より
あるAnonymous Cowardのタレコミより。Windows 8ではシステム内で時間の携速などに使われるRTC（Real Time Clock）がCPUクロックの変動に応じて変わるため、ベンチマークツールによる正確なベンチマークテストが行えないという話題がEngadgetで紹介されている。
発端は、ベンチマーク集計サイトHWBOTが、「RTCはオーバークロック/アンダークロックの影響を受けて変動するため信頼できない」としてWindows 8でのベンチマークテスト結果については登録できないと発表したという。RTCが変動するとなると、正確な時間は計測できず、その結果ベンチマークテスト結果についても不正なものになるという話だ。
HWBOTでは「OSの下でのオーバークロック/アンダークロック」がRTCに影響を及ぼすとしているが、最近では消費電力や発熱を抑えるため、小まめにCPUクロックを変動させるのが一般的だ。これについても影響するのかどうかは明らかにされていない。また、この問題はCPUによって発生するものとしないものがあるという。Windows 8.1のプレビュー版でもこの問題は解決されていないそうだ。
いっぽう、「PCMark」や「3DMark」といったベンチマークソフトで有名なFuturemark社はこの問題に対し、「3DMarkについてはこの影響は受けず、何も問題無い」とのコメントを出している。
一般ユーザには影響なし (スコア:5, 参考になる)
相変わらずひどいタレコミで、まるでWindows 8が日常の利用で影響あるような書きぶりですが、
futuremarkのリリースを読むと、不正の目的で意図的にハードウェア改造しないと発生しない問題とのことで、要するに気にする必要なしです。
futuremarkはこの改造をはっきり「exploit」と呼んでいます。
以下引用します。
>the exploit described by HWBot has no practical benefit for hardware manufacturers or PC gamers since it only serves to create a false score that does not reflect actual performance.
（HWBotが発表したexploitは、ハードウェアメーカーやPCゲーマーに実用的な利益はなく、実際の性能に影響しない偽のベンチマークスコアを生み出すためだけのものです。）
>Furthermore, the steps required to exploit this issue are quite unusual and could not be happened upon by accident.
（さらに、この問題を発生させるための操作手順は、まったく日常的なものではなく、意図せずに発生することはあり得ません。）
また、以下のようにもコメントしています。
>Windows 8 systems that have been overclocked by modifying the CPU multiplier through the BIOS - whether manually or preconfigured by a reseller - are unaffected.
（（ユーザの）手動操作であれ、販売業者による事前設定によるものであれ、BIOSを通じてCPUクロックを変更することでオーバークロックしている限り、この問題は発生しません。）
要するに、意図的なハードウェア改造により、Windows 8のクロックを騙す方法が発見されたため、Windows 8を使えばベンチマークの数値を偽造することができるということです。
これは実際の性能には影響がなく、通常の利用で発生するようなものでもありませんが、ベンチマークを実際以上に大きく見せたいときに悪用できますよ、ということです。
オーバークロッカーにとっては気になる情報で、HWBotがWindows 8による計測結果を拒否するのもやむなししょうが、
一般ユーザが大騒ぎするような話でもないと思います。
Re:一般ユーザには影響なし (スコア:2, 参考になる)
HWBOTのページによれば，
1. BCLK を130MHz， CPU ratio を 32倍にして起動（CPUは4160GHzで動作）．
2. OS経由で BCLK を 122MHz に下げ，CPU ratio は 34倍にする (CPUはかわらず4160GHzで動作)．
という手順だそうです．そのテのツールを使えば，誰でも再現できそうです．
おおさわぎする必要はない，というのは同意です．最近は，OS起動してからでもクロック周波数変えたり普通にできるんだあ，
と少し感動でした．
Re:一般ユーザには影響なし (スコア:2, 参考になる)
それこそ、事故なのか意図的なのかわかりませんが、
HWBotはwindows8だとベンチマーク結果を「偽装できる」ので採用しないと言っただけ。
それが報道されると「Windows8はCPUクロックが変わると（昔のコンピュータのごとく）コンピュータが正常に動作しない」になるのは困ったものです。
今時そんなわけないがね。
Re:一般ユーザには影響なし (スコア:1)
最近の/.jはアクセスを稼ぐためか、釣り目的の記事が多いように思います。
いっその事2chまとめサイト風に、タイトルを
【悲報】Windows 8はCPUクロックの変更がRTCに影響するため、正しいベンチマークが行えない?
とかにしてくれると、なんか落ち着いて読めるんじゃという気がしますね。
【アンチ歓喜】【閲覧注意】【また日経】とかもおすすめ。
Re: (スコア:0)
>相変わらずひどいタレコミで、まるでWindows 8が日常の利用で影響あるような書きぶりですが、
ああ、いつものスラドクオリティってやつか…
日経や朝日を笑えないよね
どっちかよくわからんな (スコア:2)
RTCに問題があるのかCPUがRTCに影響を受けるのか・・・
RTCが狂うって (スコア:1)
オーバークロックなんざ興味は無い、しかしOSのRTCが信用できないって大問題な気がするんだが…
あと独立したハードウェアのRTCがなんでCPUのクロックで狂うのかも理解できない。
技術的な詳細が欲しい。
Re:RTCが狂うって (スコア:3)
> あと独立したハードウェアのRTCがなんでCPUのクロックで狂うのかも理解できない
自分もどんな仕組みでそうなってるのか気になりますね。
一応リンク先を見ると、
CPUについては、Intel 環境では Haswell / Ivy Bridge / Sandy Bridge / Gulftown / Wolfdale で発生を確認済み。なお AMD 環境では問題なしという検証結果が出ています。
ということで、Windows 8とintelの組み合わせで発生するようです。
Windows8でのRTCの仕様変更により、Intel固有のなにかの機能が影響してるようなので、
Win8のRTCにどんな仕様変更があったのか、影響しているIntel固有の機能は何か、
の2点を明らかにすれば十分なんですが。。
Re:RTCが狂うって (スコア:5, 参考になる)
更にリンク先 [hwbot.org]を見ると、OS起動時に取得したであろう仕様から起動後にOS上からベースクロックと倍率を変更しているようです。
# つまり、通常の省電力等と違いOSが関知しない所でシステム構成が変動してるのですね。
また、記事中では"RTC"とか言ってますが、実際はOSの時計=システムクロックであって、ハードウェアクロックである物理的なRTCでは無い模様。
よって、割り込みタイミングがOS起動後に変わってしまってシステムクロックが狂うってのが真相なのでは？
# LinuxもBIOS含めたHWの不具合やらVM [vmware.com]だったりでシステムクロックが狂う対策に苦しんでたりしますがOS起動中にベースクロック変動をやられた場合どうなるんだろう？
一応原因として有りそうなのはHPETとか諸々の割り込み辺りがベースクロックと同期しちゃってるとか。
OSの影響はシステムクロックのソースが仕様変更されたので顕在化とかかなぁ？
尚IntelのみなのはIntel固有の機能(含むチップセットドライバ等)もですが、M/Bやチップセットが何か公開されてない以上、BIOS/UEFI(含むマイクロコード)やオーバークロックツールの共通不具合の可能性も考慮すべきかと。
Re:RTCが狂うって (スコア:1)
OS上から変更できても、OSが関知してるかは別です。
クロックの変更やBIOS等のファームウェア更新だってOS上から可能ですが、それはハード側がそのような機能を実装していて、ドライバ経由等で叩いてるだけですから。
結果、ベースクロックや倍率が変わった事を誰からも知らされなければ対処しようがありません。
Re:RTCが狂うって (スコア:3, 参考になる)
AMDのTSCは800Mhz固定、Intelはクロックにより変動。多分RTCにアクセスするとシステム時間にフォールバックするとかでは。
なのでRTCの性質を前提にしているベンチマークは結果が変わるとか。
Re:RTCが狂うって (スコア:1)
RTCそのものじゃなくて、OSがカウントアップしている部分がおかしいんじゃないですかね。
RTCはアクセスに時間がかかるし精度も低いですから、今どきのOSは起動時にRTCを読み取った後、別の手段で時間を進めているはず。この部分がバグっているということなのかな？
Re:RTCが狂うって (スコア:2)
Re: (スコア:0)
普通RTCと言えばハードだよね。
でもOSは往々にして立ち上げ時にRTCから値を読み、その後は内部カウントしてって事をやっているものだから
（でないと時間問い合わせの度にI/O処理が発生しちゃう。が最近のリッチなOSでは常時に時間表示とかするものだし）
そのカウントの処理の中で、カウントを間違えさせられるO/Cのパターンが見つかったってのかな？
Re: (スコア:0)
Really-ish Time Clock だったんだよ
どこまで精度が必要なのか？ (スコア:1)
こういうのは、極端に精度を上げれば、コストに直結するのも現実。
さて、どれくらいの精度が欲しいですか？
Re: (スコア:0)
今のPCには、100ナノ秒程度の精度があるタイマーが既に乗っていますよ。
http://ja.wikipedia.org/wiki/High_Precision_Event_Timer [wikipedia.org]
Re:どこまで精度が必要なのか？ (スコア:1)
そして、OS 込みのシステムとしての精度はどれくらいなんでしょうか？
例えば、24時間連続稼働で、どれくらいのズレなら問題無いと思えますか？
確かに、細かく時間が計れるのも、大切なんですがね。
Futuremark社は"exploit"と表現 (スコア:1)
偽のスコアを出すだけで実際の性能には全く影響しない、またこの現象を発生させる手続きは通常の使い方とかけ離れていて、偶然に起こることはありそうもない、と言っていますね。
ベンチマークの数値を競うサイトではチートに使われる恐れがあるけど、普通に時間を計測する用途で問題になることは無いという見解のようです。また、このチートを検出するのは容易だろうとも。
すると (スコア:1)
実行するたびに亜美の腰振りスピードが変わるんですね？
らじゃったのだ
Re:すると (スコア:1)
ビンタ ベンチ （そしておっさんホイホイ） というとやっこちゃんがチャチャをビンタしてる
「チャチャベンチ」が思い浮かぶんだけどそれかな？
＃リーヤ＋しいねでリーネ？
らじゃったのだ
性能 (スコア:0)
省電力機能も含めての正しい性能なんじゃ無いだろうか？
過剰な冷却を行った上での非実用的なフルパワーの方が意味の無い数字にしか思えない。
問題点が違う (スコア:1)
ちがうちがう。
「t秒間にn個の処理をこなした」を測りたいのに、
そのt秒を正確に測れないという話です。
よくわからん (スコア:0)
Windowsには明るくないけど、
CPUクロックの影響を受けるってことは、TimeStampCounter由来のカウンターってこと、なら実時間の計測に使うのがそもそも間違ってるんじゃないの。
今時のPCでHPETに対応してない奴なんてないでしょ、vista以降なら対応しているし、
ベンチマークのことは脇に置いて、 (スコア:0)
OS の時計がクロック低下に伴い、時刻を遅く刻む。ってのはかなり問題じゃないかな？
取り敢えず、終電お知らせタイマーは Windows のフリーウェアから iPad の時計に切り替えよう。
Re: (スコア:0)
大丈夫。終電間際になるとコンパイルしまくってるはずだから、クロックが低下してるなんてあり得ないよ。
Re:ベンチマークのことは脇に置いて、 (スコア:2)
Re: (スコア:0)
Windowsは伝統的に常にRTCを読んでいるわけじゃない。
昔は、レジュームすると時計が狂っているのはしょっちゅうだった。(RTC自体は狂ってないので、再起動で治る)
たぶん、時計の仕様をタイマー割り込みからTSCに変えたとかそういう話なんじゃないかな。
ベースクロックを変えるのは規定外の動作という扱いなんでしょ。
Re: (スコア:0)
ごめーん。V-Syncで数えていたわ、てへっ。というオチになると思う。
RTCとか (スコア:0)
CPUのクロックが可変するなら別系統のクロックを供給すべきじゃないんですかね？
これじゃCPUチックカウントと何が違うんだか
Re: (スコア:0)
TTC(Truth Time Clock)とか
MTC(Master Time Clock)とか
PTC(Primary Time Clock)とか
#もはや元祖と本家の争い
まちがい (スコア:0)
×時間の携速
○時間の計測
Re:まちがい (スコア:2)
Windows8は (スコア:0)
RTCが不正確でも困らない用途向けのOSってことでしょ
そんな用途がどれくらいあるのかはは知らないけど
AMD環境なら発生しない (スコア:0)
intel環境のみで生じるらしいので、OSの問題か、CPUの問題か、ようわからんな
アムダー歓喜 (スコア:0)
もしまだアムダーの生き残りがいるなら、だが。
おまえはクビだ！ (スコア:0)
ドク「PCにジゴヘルツ単位の信号を送るとPCがタイムスリップするのだ」
ソースは２ｃｈなんだが (スコア:0)
ああ、２ｃｈでwindows8はCPUクロックの変更されてるって言われてたのはマジだったのか。
2ch って結構事実がでるんだよ (スコア:0)
雑談の /J よりは。
ウソも多いけどね
Re: (スコア:0)
ニポンゴで4649
普通はHPET使うんじゃないの？ (スコア:0)
時計アプリ見ながらの検証になってるけど…。
ベンチソフトとかは普通QueryPerformanceCounter使うだろうし
Vista以降HPETを利用することが期待できるからそっちで計算を蓄積してりゃ
少なくともクロック変動の影響は受けないと考えて良かったんじゃないけ？
Re:普通はHPET使うんじゃないの？ (スコア:1)
Windowsを含む今時のOSは、RTCから読み取るのは起動だけで、
あとは、OSが内部的に持つ高精度タイマを累算することで現在時刻を算出します。
つまり、時計アプリの表示が狂うということは、OSが内部で管理している高精度タイマの精度が狂っている、ということです。
単純にOSのバグ (スコア:0)
カレンダーRTCにCPUクロックが影響するってそんな馬鹿なとタレコミ元みたら、
右下の時間表示が狂う検証動画があった。
しかも、windows7では問題無く、8で発生するようになったってことはソフト的に発生しているってことだろう。
--- それって、単純にバグじゃん。
おそらく、32kHz原発RTCから起動時にCPUソフトカウンタにコピーしてその後CPUソフトカウンタで
計時しているとか、そんなとこだろう。
これが仕様などというなら、大問題。ベンチマークどころでなく
時刻使用するクリチカルなシステム(株取引とかチケット発券とか)には全く使えない。
セキュリティ脆弱性に同等以上の影響のある深刻なバグだと思う。
Re:単純にOSのバグ (スコア:1)
OSのバグ？
やだなぁ。
仕様ですよ、仕様。
Re: (スコア:0)
タレコミ元みるだけじゃなくて読めよ...頭がバグってるの？
Re: (スコア:0)
読む以前にそもそもRTCがなんなのか知ってないからバグ以前の問題。
＃まあタレコミもタレコミだが
なんか勘違いしているコメントが多いようだが (スコア:0)
TSCの速度は実測しないと分からないので、WindowsだろうとLinuxだろうと*BSDだろうと、OS起動時にキャリブレーションしています。その後で外部供給クロックを変動させると、時計が狂うのは当然ですよね。
アイドル時にクロックを落とすとか、TurboBoostとかいうのは話が別で、そもそもOSが自らクロックを変えるのでちゃんと補正しますし、そもそも現在主流のCPUではこれらの (内部の) クロック変動でTSCの速度が変わることはありません。
Re: (スコア:0)
というか、ストーリー自体が勘違いしてるんだな。
Re:なんか勘違いしているコメントが多いようだが (スコア:2)
HPETを使っているだろうと思っていて確認していなかったけど、調べてみるとTSCっぽい雰囲気。
／(^o^)＼
BIOS設定でCPUの最大動作周波数を変えて起動すると、露骨に値が違うし。
但し、OSはWindows 7。
Re:なんか勘違いしているコメントが多いようだが (スコア:2)
bcdedit /set useplatformclock true
して再起動すれば、HPETを使うようになる。