System.Diagnostics.Stopwatch.Netは、クラスを使用した高解像度タイミングをサポートしています。このクラスが使用する特定の解像度は、基盤となるハードウェアによって異なり、静的プロパティを介して取得できることを理解していますStopwatch.Frequency。
この頻度はCPU頻度に関連しているようStopwatchで、この値を読み取り、静的初期化子/コンストラクター内の静的クラス変数に格納します。したがって、CPUクロックが変更された場合に、このクラスが誤ったタイミングを報告するかどうか疑問に思っていますか？たとえば、システムの負荷に応じてCPUクロックを変更するシステム。
MSDN：
*The Frequency value depends on the resolution of the underlying timing mechanism. If the installed hardware and operating system support a high-resolution performance counter, then the Frequency value reflects the frequency of that counter. Otherwise, the Frequency value is based on the system timer frequency.*
Stopwatch.FrequencyのソースはCPU周波数ではありません。高周波ハードウェアカウンターの周波数です。Windowsでは、このカウンター周波数は通常、QueryPerformanceCounter関数の呼び出しによっても読み取られますが、Linuxでは、高解像度のPOSIXタイマーを使用して高解像度のタイミングを取得します。
タイムスタンプカウンター（RDTSC-CPU周波数）の使用は、このコンテキストでよく説明されますが、実際の関連性はありません。
一部の古いハードウェアは、タイミングの目的で高周波ハードウェアを提供しない場合があるため、CPUの周波数が代わりに使用されます。タイミングにCPU周波数を使用する場合、周波数が一定に保たれるように確保する必要があります。最新のハードウェアは、動的なCPU周波数変更を提供します。動的に変更されているときにCPU周波数を測定値として使用すると、混乱が発生します。
幸いなことに、これはnon existing状況です。CPU周波数を変更できるシステムはより近代的です。このような最新のシステムには、別個の高周波タイマーハードウェアHigh PrecisionEventTimerもあります。
マルチコアシステムでCPU周波数を使用することについていくつかの噂があります。実際、特定のハードウェアに問題があります。しかし、それはずっと前のことであり、しばらくの間修正されました。