【こういう事だった!】Windows8でRTC(リアルタイムクロック)が狂う問題

Windows8.1が発売され、思い出したのが「Windows8はCPUクロック変更でベンチマーク結果に影響がある? について」の問題。

あの問題は結局何が問題だったのか?
もう情報も出ているだろうと、調べてみました。

先ず、どんな問題だったのか?
<引用>
ある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についてはこの影響は受けず、何も問題無い」とのコメントを出している。

ってな問題です。

また、AMD製CPUでは問題が発生していなかったり、インテル製CPUでも発生するのは割とモダンな(Coreプロセッサ)CPU以降で発生しているらしい。


結果から言うと一般ユーザが大騒ぎするような話でもないという事です。

これは「一般ユーザーがベンチマークなんて動かしたりしない」とか「RTCが狂ってカレンダーとかのアプリがおかしくなったりする」なんて事ではありません。

では、何?
こういう情報がありました。
((ユーザの)手動操作であれ、販売業者による事前設定によるものであれ、BIOSを通じてCPUクロックを変更することでオーバークロックしている限り、この問題は発生しません。)

要するに、意図的なハードウェア改造により、Windows 8のクロックを騙す方法が発見されたため、Windows 8を使えばベンチマークの数値を偽造することができるということです。
これは実際の性能には影響がなく、通常の利用で発生するようなものでもありませんが、ベンチマークを実際以上に大きく見せたいときに悪用できますよ、ということです。

当然、win8以前にリリースされているベンチマークがこの手の悪さを悪意を持って作られているとは考えられないので、何故こんな誤解を持ってしまう(最初の)記事を書いてしまったんでしょうかねぇ?(それこそwin8に対する悪意があったんじゃないの?って邪推します)

他にも
HWBOTのページによれば,

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

という手順だそうです.そのテのツールを使えば,誰でも再現できそうです.
おおさわぎする必要はない,というのは同意です.最近は,OS起動してからでもクロック周波数変えたり普通にできるんだあ,
と少し感動でした.

とあり、結局OS(Win8)はCPUとかの入力クロックが変更された事をBIOSレベルでしか管理していないって事ですかねぇ?BIOSを使わず現在の(本当の)クロックを読み取る方法なんてありそうだが、そうはしていないって事なのか。で、悪意のあるプログラムはハードウェアを直接叩いてクロックを変更させているんだろう。

どっかのレジスタに基本クロックと逓倍率(ていばいりつ)の設定値があったりしないのかな?(組み込み系の仕事してた時はインテル以外のハードをよく使っていたが、普通に設定値は読めた)

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

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

困ったモンです(´・ω・`)
WIN8を入れただけでWIN7以前に購入したPCでもタッチ操作できる様になると思ってた人レベルだと完全に誤解するよねw

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

タイマーじゃなくてカウンターの方の問題ですよね。
IBM-PCの(RTC周りの)アーキテクチャーは8086時代の頃とそう変わってないんでしょうかねぇ?アーキテクチャーは一緒でもチップレベルで性能を上げたりしてないのかなぁ?ホント今時のマシンのタイマー精度としては悪い。

Windows 8 RTC Bug analyzed and fixed!
ここにACPIタイマー、HPETタイマー、RTCタイマー、QPCタイマーのクロックと時間の経過を計測するツールを使用して、インテルとAMDとでRTC問題の検証を行っています。

こんな情報もあります。
Intelプラットフォームでは、BCLKを95MHzに下げるとRTC/QPCが狂いましたが、BIOS上で95MHzに設定した場合は、QPCクロックがBCLKを元に変更され、正しい時間が刻まれるようになっています。どうやら、Windows上でツールを用いてBCLKを変更すると、影響を受けるようです。

さらに
AMDプラットフォームでは、バスクロックを200→180MHzに下げた場合、QPCのクロックがHPETと同じクロックになることで問題が回避され、さらに、BIOSでHPETを無効にした場合、ACPIと同じクロックになるようです。

また、AMDプラットフォームでインストールされたWindows 8を、Intelプラットフォームに接続した場合、RTC問題の影響を受けなかったそうで、この両者の違いについて調べたところ、「BCDedit」というコマンドにおける、とあるパラメーターの有無の違いが見つかったそうです。そのパラメーターとは「useplatformclock」で、AMDプラットフォームにのみ存在し、値は「Yes」に設定されているとのこと。そして、このパラメーターをIntelプラットフォームで追加したところ、RTC問題の影響を受けなくなったそうです。ちなみに、Windows 7でもBCLKを下げるとQPCタイマーが影響を受けますが、useplatformclockの値を追加することで、影響を受けなくなるとのこと。

なんて事が書かれていました。

OSがあらゆるハードに対して、ハードウェアを抽象化したり、互換性を持たせたりする事の難しさを見たと感じました(゚Д゚)

Microsoft Windows 8.1 (DSP版) 64bit 日本語
マイクロソフト(DSP)
2013-10-18

amazon.co.jpで買う
Amazonアソシエイト by Microsoft Windows 8.1 (DSP版) 64bit 日本語 の詳しい情報を見る / ウェブリブログ商品ポータル


Microsoft Windows 8.1 Pro (DSP版) 64bit 日本語 発売記念パック
マイクロソフト(DSP)
2013-10-18

amazon.co.jpで買う
Amazonアソシエイト by Microsoft Windows 8.1 Pro (DSP版) 64bit 日本語 発売記念パック の詳しい情報を見る / ウェブリブログ商品ポータル

この記事へのコメント

この記事へのトラックバック