「Windows 8はCPUクロックの変更がRTCに影響するため、正しいベンチマークが行えない？」記事へのコメント

RTCが狂うって

[Anonymous Coward]

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

Re:

[t-wata (10969)]

> あと独立したハードウェアのRTCがなんでCPUのクロックで狂うのかも理解できない

自分もどんな仕組みでそうなってるのか気になりますね。
一応リンク先を見ると、

CPUについては、Intel 環境では Haswell / Ivy Bridge / Sandy Bridge / Gulftown / Wolfdale で発生を確認済み。なお AMD 環境では問題なしという検証結果が出ています。

ということで、Windows 8とintelの組み合わせで発生するようです。
Windows8でのRTCの仕様変更により、Intel固有のなにかの機能が影響してるようなので、
Win8のRTCにどんな仕様変更があったのか、影響しているIntel固有の機能は何か、
の2点を明らかにすれば十分なんですが。。

Re:RTCが狂うって

[kei100 (5854)]

更にリンク先 [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:

[Anonymous Coward]

# つまり、通常の省電力等と違いOSが関知しない所でシステム構成が変動してるのですね。

コメントへの反応ですみませんが，「OS上からベースクロックと倍率を変更」してるのですから，OSは当然関知してますよね．
OSに問題なし，とは言えないです．

ハードウェアのRTCは無関係というのは同意です．

Re:RTCが狂うって

[kei100 (5854)]

コメントへの反応ですみませんが，「OS上からベースクロックと倍率を変更」してるのですから，OSは当然関知してますよね．
OSに問題なし，とは言えないです．

OS上から変更できても、OSが関知してるかは別です。
クロックの変更やBIOS等のファームウェア更新だってOS上から可能ですが、それはハード側がそのような機能を実装していて、ドライバ経由等で叩いてるだけですから。
結果、ベースクロックや倍率が変わった事を誰からも知らされなければ対処しようがありません。

Re:

[Anonymous Coward]

狂った時間がsystohcされてしまうってことはないのかな?