Bus and core clock can be wrong when SetFSB is used

[GoogleCodeExporter]

When SetFSB is used to change the FSB while Windows is running, this can lead 
to the following situation:

- Change in FSB means the TSC changes also.
- The Open Hardware Monitor uses Stopwatch.GetTimestamp() to measure time. 
- The Stopwatch class usually relies usually on QueryPerformanceCounter and 
QueryPerformanceFrequency which again is using the TSC on some systems.
- QueryPerformanceFrequency is documented as: "The frequency cannot change 
while the system is running.", but changing the TSC would also require a change 
in QueryPerformanceFrequency.
- Measuring the the time based on a wrong frequency yields wrong results 
- The measured TSC and as a consequence the measured FSB does not change when 
the wrong TSC frequency is used for the estimate

One workaround would be to use the following Stopwatch class:

internal static class Stopwatch {
  public static long GetTimestamp() {
    return System.DateTime.UtcNow.Ticks;
  }
  public static long Frequency {
    get { return 10000000; }
  }
}

This gives more or less correct results even when the FSB is changed while 
Windows is running. But the accuracy of the underlying timer seems not to be 
good enough.

Beside this, the Intel Core 2 bus and core clock implementation assumes a 
constant FSB (which is estimated only during startup of the Open Hardware 
Monitor), so even with a fixed timer implementation one would need to restart 
the Open Hardware Monitor to get correct results.

Original issue reported on code.google.com by moel.mich on 3 Oct 2010 at 3:21