It’s kind of curious that there’s a bit of a ruckus going on with regards to benchmarking accuracy on Windows 8. From what I’ve heard, the actual cause of the inaccuracy is quite simple:
Windows 8 appears to use the processor’s TSC as a timing source on modern processors. There is absolutely nothing wrong with this: it provides a very fast high resolution timing source as long as the TSC on the processor runs constantly and at the same rate. Modern Intel processors set CPUID bits that indicate this to be the case (nonstop_tsc
and constant_tsc
). Linux has supported using the TSC for timing for several releases, with no issues.
The only catch is that to turn the TSC into a clock source, it has to be calibrated against an external clock. Linux does this once at boot, calculating the value based on the processor’s reported frequency and double-checking against a realtime clock. Presumably Windows 8 does something similar.
The problem with the benchmarks comes in only on overclocked (or underclocked) systems where the clock speed of the processor is changed while the system is running, using for example a utility provided by the motherboard manufacturer. These utilities usually change the base clock rate that the processor is using as a reference. The key point: This changes the speed at which the TSC runs. And the utilities don’t bother telling the operating system to recalibrate the clock; presumably there is no standard API to do so.
So, what can be done? I don’t know. But if motherboard manufacturers want to push in-OS overclocking solutions, they’re presumably going to have to pressure Microsoft into offering an API to tell the Windows timesource to recalibrate the TSC clock, or even just tell Windows to switch to an older, less performant timing mechanism.
Leave a Reply