パスワードを忘れた? アカウント作成
9848423 story
Windows

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についてはこの影響は受けず、何も問題無い」とのコメントを出している

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2013年08月23日 10時50分 (#2446490)

    相変わらずひどいタレコミで、まるで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による計測結果を拒否するのもやむなししょうが、
    一般ユーザが大騒ぎするような話でもないと思います。

    • by Anonymous Coward on 2013年08月23日 12時39分 (#2446573)
      このコメントもミスリーディングのような...「意図的なハードウェア改造」はいらないですよ.
      HWBOTのページによれば,

      1. BCLK を130MHz, CPU ratio を 32倍にして起動(CPUは4160GHzで動作).
      2. OS経由で BCLK を 122MHz に下げ,CPU ratio は 34倍にする (CPUはかわらず4160GHzで動作).

      という手順だそうです.そのテのツールを使えば,誰でも再現できそうです.
      おおさわぎする必要はない,というのは同意です.最近は,OS起動してからでもクロック周波数変えたり普通にできるんだあ,
      と少し感動でした.
      親コメント
    • by Anonymous Coward on 2013年08月23日 12時41分 (#2446578)

      それこそ、事故なのか意図的なのかわかりませんが、
      HWBotはwindows8だとベンチマーク結果を「偽装できる」ので採用しないと言っただけ。

      それが報道されると「Windows8はCPUクロックが変わると(昔のコンピュータのごとく)コンピュータが正常に動作しない」になるのは困ったものです。
      今時そんなわけないがね。

      親コメント
    • by Anonymous Coward on 2013年08月23日 11時30分 (#2446528)

      最近の/.jはアクセスを稼ぐためか、釣り目的の記事が多いように思います。

      いっその事2chまとめサイト風に、タイトルを

      【悲報】Windows 8はCPUクロックの変更がRTCに影響するため、正しいベンチマークが行えない?

      とかにしてくれると、なんか落ち着いて読めるんじゃという気がしますね。

      【アンチ歓喜】【閲覧注意】【また日経】とかもおすすめ。

      親コメント
    • by Anonymous Coward

      >相変わらずひどいタレコミで、まるでWindows 8が日常の利用で影響あるような書きぶりですが、

      ああ、いつものスラドクオリティってやつか…
      日経や朝日を笑えないよね

  • RTCに問題があるのかCPUがRTCに影響を受けるのか・・・

  • by Anonymous Coward on 2013年08月23日 8時32分 (#2446372)

    オーバークロックなんざ興味は無い、しかしOSのRTCが信用できないって大問題な気がするんだが…
    あと独立したハードウェアのRTCがなんでCPUのクロックで狂うのかも理解できない。
    技術的な詳細が欲しい。

    • by t-wata (10969) on 2013年08月23日 9時21分 (#2446406) 日記

      > あと独立したハードウェアの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, 参考になる)

        by kei100 (5854) on 2013年08月23日 12時14分 (#2446558)

        更にリンク先 [hwbot.org]を見ると、OS起動時に取得したであろう仕様から起動後にOS上からベースクロックと倍率を変更しているようです。
        # つまり、通常の省電力等と違いOSが関知しない所でシステム構成が変動してるのですね。

        Boot in OS at 130MHz BCLK and 32x CPU Ratio
        Reduce BCLK frequency to 122MHz at runtime (in OS). Set CPU ratio at 34x to maintain the same frequency of 4160 MHz
        Check benchmark before and after the downclock

        また、記事中では"RTC"とか言ってますが、実際はOSの時計=システムクロックであって、ハードウェアクロックである物理的なRTCでは無い模様。
        よって、割り込みタイミングがOS起動後に変わってしまってシステムクロックが狂うってのが真相なのでは?
        # LinuxもBIOS含めたHWの不具合やらVM [vmware.com]だったりでシステムクロックが狂う対策に苦しんでたりしますがOS起動中にベースクロック変動をやられた場合どうなるんだろう?

        一応原因として有りそうなのはHPETとか諸々の割り込み辺りがベースクロックと同期しちゃってるとか。
        OSの影響はシステムクロックのソースが仕様変更されたので顕在化とかかなぁ?
        尚IntelのみなのはIntel固有の機能(含むチップセットドライバ等)もですが、M/Bやチップセットが何か公開されてない以上、BIOS/UEFI(含むマイクロコード)やオーバークロックツールの共通不具合の可能性も考慮すべきかと。

        --
        誰も信じちゃいけない、裏切られるから。
        私を信じないで、貴方を裏切ってしまうから。
        親コメント
      • Re:RTCが狂うって (スコア:3, 参考になる)

        by Anonymous Coward on 2013年08月23日 9時27分 (#2446409)

        AMDのTSCは800Mhz固定、Intelはクロックにより変動。多分RTCにアクセスするとシステム時間にフォールバックするとかでは。
        なのでRTCの性質を前提にしているベンチマークは結果が変わるとか。

        親コメント
    • RTCそのものじゃなくて、OSがカウントアップしている部分がおかしいんじゃないですかね。
      RTCはアクセスに時間がかかるし精度も低いですから、今どきのOSは起動時にRTCを読み取った後、別の手段で時間を進めているはず。この部分がバグっているということなのかな?

      --
      へ へ
      の の
      親コメント
      • by saitoh (10803) on 2013年08月23日 10時57分 (#2446498)
        普通RTCといったら「マザーボードに付いている時計モジュールのことで、こいつはCPUクロックとは別に独自の水晶発振子を持ってて電源が切れてても(ボタン電池で)動き続ける」やつのことだとおもってたんですが、この文脈では何か違うものをさしてRTCと呼んでいるようですね。 Windowsの時刻サービスかなにか?
        親コメント
        • by Anonymous Coward

          普通RTCと言えばハードだよね。
          でもOSは往々にして立ち上げ時にRTCから値を読み、その後は内部カウントしてって事をやっているものだから
          (でないと時間問い合わせの度にI/O処理が発生しちゃう。が最近のリッチなOSでは常時に時間表示とかするものだし)
          そのカウントの処理の中で、カウントを間違えさせられるO/Cのパターンが見つかったってのかな?

    • by Anonymous Coward
      Real Time Clock じゃなく
      Really-ish Time Clock だったんだよ
  • デスクトップなら、1/100sec くらいは欲しいと思う。

    こういうのは、極端に精度を上げれば、コストに直結するのも現実。

    さて、どれくらいの精度が欲しいですか?
  • by Anonymous Coward on 2013年08月23日 10時45分 (#2446484)

    Before panicking, it is worth clarifying that 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. Furthermore, the steps required to exploit this issue are quite unusual and could not be happened upon by accident.

    偽のスコアを出すだけで実際の性能には全く影響しない、またこの現象を発生させる手続きは通常の使い方とかけ離れていて、偶然に起こることはありそうもない、と言っていますね。
    ベンチマークの数値を競うサイトではチートに使われる恐れがあるけど、普通に時間を計測する用途で問題になることは無いという見解のようです。また、このチートを検出するのは容易だろうとも。

  • by PEEK (27419) on 2013年08月23日 10時47分 (#2446486)

    実行するたびに亜美の腰振りスピードが変わるんですね?

    --
    らじゃったのだ
    進め!恋する乙女♪
    その戦闘氏族の成れの果てがこれ
  • by Anonymous Coward on 2013年08月23日 8時19分 (#2446358)

    省電力機能も含めての正しい性能なんじゃ無いだろうか?
    過剰な冷却を行った上での非実用的なフルパワーの方が意味の無い数字にしか思えない。

  • by Anonymous Coward on 2013年08月23日 8時26分 (#2446365)

    Windowsには明るくないけど、
    CPUクロックの影響を受けるってことは、TimeStampCounter由来のカウンターってこと、なら実時間の計測に使うのがそもそも間違ってるんじゃないの。
    今時のPCでHPETに対応してない奴なんてないでしょ、vista以降なら対応しているし、

    • OS の時計がクロック低下に伴い、時刻を遅く刻む。ってのはかなり問題じゃないかな?

      取り敢えず、終電お知らせタイマーは Windows のフリーウェアから iPad の時計に切り替えよう。

    • by Anonymous Coward

      Windowsは伝統的に常にRTCを読んでいるわけじゃない。
      昔は、レジュームすると時計が狂っているのはしょっちゅうだった。(RTC自体は狂ってないので、再起動で治る)

      たぶん、時計の仕様をタイマー割り込みからTSCに変えたとかそういう話なんじゃないかな。
      ベースクロックを変えるのは規定外の動作という扱いなんでしょ。

      • by Anonymous Coward

        ごめーん。V-Syncで数えていたわ、てへっ。というオチになると思う。

  • by Anonymous Coward on 2013年08月23日 8時31分 (#2446371)

    CPUのクロックが可変するなら別系統のクロックを供給すべきじゃないんですかね?
    これじゃCPUチックカウントと何が違うんだか

    • by Anonymous Coward
      RTCがアテにならないなら別供給するしかないですよね。

      TTC(Truth Time Clock)とか
      MTC(Master Time Clock)とか
      PTC(Primary Time Clock)とか

      #もはや元祖と本家の争い
  • by Anonymous Coward on 2013年08月23日 9時06分 (#2446393)

    ×時間の携速
    ○時間の計測

  • by Anonymous Coward on 2013年08月23日 9時12分 (#2446398)

    RTCが不正確でも困らない用途向けのOSってことでしょ
    そんな用途がどれくらいあるのかはは知らないけど

  • by Anonymous Coward on 2013年08月23日 9時33分 (#2446413)

    intel環境のみで生じるらしいので、OSの問題か、CPUの問題か、ようわからんな

  • by Anonymous Coward on 2013年08月23日 9時33分 (#2446414)

    ドク「PCにジゴヘルツ単位の信号を送るとPCがタイムスリップするのだ」

  • by Anonymous Coward on 2013年08月23日 10時00分 (#2446440)

    ああ、2chでwindows8はCPUクロックの変更されてるって言われてたのはマジだったのか。

  • by Anonymous Coward on 2013年08月23日 10時24分 (#2446462)

    時計アプリ見ながらの検証になってるけど…。
    ベンチソフトとかは普通QueryPerformanceCounter使うだろうし
    Vista以降HPETを利用することが期待できるからそっちで計算を蓄積してりゃ
    少なくともクロック変動の影響は受けないと考えて良かったんじゃないけ?

  • by Anonymous Coward on 2013年08月23日 10時54分 (#2446495)

    カレンダーRTCにCPUクロックが影響するってそんな馬鹿なとタレコミ元みたら、
    右下の時間表示が狂う検証動画があった。
    しかも、windows7では問題無く、8で発生するようになったってことはソフト的に発生しているってことだろう。
    --- それって、単純にバグじゃん。
    おそらく、32kHz原発RTCから起動時にCPUソフトカウンタにコピーしてその後CPUソフトカウンタで
    計時しているとか、そんなとこだろう。
    これが仕様などというなら、大問題。ベンチマークどころでなく
    時刻使用するクリチカルなシステム(株取引とかチケット発券とか)には全く使えない。
    セキュリティ脆弱性に同等以上の影響のある深刻なバグだと思う。

  • by Anonymous Coward on 2013年08月23日 11時08分 (#2446508)

    TSCの速度は実測しないと分からないので、WindowsだろうとLinuxだろうと*BSDだろうと、OS起動時にキャリブレーションしています。その後で外部供給クロックを変動させると、時計が狂うのは当然ですよね。
    アイドル時にクロックを落とすとか、TurboBoostとかいうのは話が別で、そもそもOSが自らクロックを変えるのでちゃんと補正しますし、そもそも現在主流のCPUではこれらの (内部の) クロック変動でTSCの速度が変わることはありません。

typodupeerror

身近な人の偉大さは半減する -- あるアレゲ人

読み込み中...