Brothers in Gaming and Tech
Currently being strewn across the internet, news of overclocking league website HWBot’s decision to ban Windows 8 submissions has gathered a lot of interest. As posted by Pieter-Jan Plaisier, the primary admin at HWBot.org, the problem stems from Windows 8’s ability to measure time.
The purpose of benchmarking is to verify an overclock, and with this comes the need to measure how fast the overclock is. The measurement is often the result of calculating a value over a time period, and measuring the rate at which the values can be calculated. There are two different ways to ‘cheat’ the score in any benchmark: change the calculation, or modify the actual time taken.
The first method of changing the calculation is hard to do on most CPU based benchmarks, short of changing the way the system calculates data. The second point of measuring the time taken is one that is more tricky to understand.
To start, we need to define system time and real time. For almost all situations, one second of real time is one second of system time. If you do X amount of work in one second of system time, that means X per second in real time to.
If the system slows down, such that X seconds of real time = 2X of system time, then the system will calculate 2X in that real time, causing a 2X score.
So why has HWBot banned Windows 8? Well it all comes down to how Windows 8 measures system time. Windows 8, when running an Intel system, can be tricked into making system time run slower than it actually is.
The method for this is relatively simple:
– Boot the system at whatever CPU speed you like
– In the operating system, reduce the BCLK
– Now the system time will be slower, resulting in more calculations per second of real time.
In HWBot’s tests, a downclock of 130 MHz BCLK to 122 MHz BCLK resulted in the system time being 18 seconds out of sync after five minutes. The result was approximately a 6% gain over various benchmarks.
How it is caused, and why it does not occur on Windows 7
Microsoft developed Windows 8 to be the operating system for all devices. As a result, there is never any guarantee of what hardware will be present when Windows 8 launches. For older versions of Windows, these were built for full PCs, meaning that the operating system had access to an external clock source, or a fixed Real-Time Clock (RTC).
Windows 8 is designed to work on systems without a fixed RTC, such that BCLK remains constant and time synchronization runs directly from the CPU – the base speed of the CPU is passed to the OS at runtime and system time is calculated as a function of these values.
Despite full system PCs having a fixed RTC as part of their design, Windows 8 fails to acknowledge this and instead uses the modular hardware present to calculate time.
What platforms are affected?
Testing by overclocker Christian Ney has revealed the following:
Windows 8 + Intel (Haswell, Ivy Bridge, Sandy, s775): Broken
Windows 8 + AMD (Trinity, AM3): No problem
Windows 7 + Intel (Haswell): No problem
Seems like an Intel issue?
Yes, and people are trying to figure out exactly why. Users are currently writing scripts to test the various timers of each processor.
What does this mean for me?
If you do not use HWBot, then this does not affect you! If you are an overclocker, then Windows 8, for the time being, is banned. Please switch to Windows 7.
If you are a user that overclocks in the OS and use Windows 8 on Intel, then any FPS results you get may be wrong. Check the accuracy of your system clock over an hour or so when not connected to the internet.
Will this decision be overturned?
It looks like Windows 8 + Intel is now done for, although as AMD seems unaffected, I would imagine AMD systems with Windows 8 being allowed in the future.
Calculating time on a computer is very complex – you are telling a system that deals with 0s and 1s to measure real-time. Without an external source (like a quartz crystal) telling you how time is moving, those 0s and 1s mean nothing. Then it is up to the system to tell the OS what all of the values are doing, and the OS has to convert that into something real.
More info on the issue as it is discovered.
Christian Ney, with help from software developed by the nice people at CPU-ID, made the following discovery with respect to the ACPI, HPET and RTC CPU timers with Haswell:
Keep 100 MHz BCLK:
Reduce BCLK to 97 MHz:
What we can see is this: When Windows 8 with an Intel chip asks for a timing call, it brings the RTC timer value. When AMD does it, it clearly uses a different timer. But in WIndows 7, it calls the same timer for both AMD + Intel. This might lead to the suggestion that there is some Intel specific code in the way Win8 reports time.
Many thanks to Christian Ney and Ocaholic for their investigative work.
Due to more investigative work by Christian Ney, we now know the full extent as to how this error occurs.
To start, we need to clarify the clocks available to the system:
ACPI Timer: Also known as PM Timer is an external hardware timer that has a fixed frequency of 3.579545 MHz.
HPET Timer: High Precision Event Timer, it is an external hardware timer that has a fixed frequency of 14.31818 MHz
RTC Timer: Real-Time Clock. It is a software timer that reads a hardware timer to count. It is being used by Windows and most software as the reference clock to measure time.
TSC Timer: TimeStampCounter. It is a hardware based timer that has a variable frequency. Its frequency was equal to the processor’s frequency and that was a problem as it would be affected by spread-spectrum and power management features lowering the processor’s clock speed implemented on newer processors. This was eventually solved in later processor designs by making the TSC clock independent of the processor frequency.
QPC Timer: or QueryPerformanceCounter is a native Windows API that access a high resolution timer and is used to calculate elapsed time. In other words a software timer that reads a hardware timer too. It was originally designed to use the TSC Timer but then modified to use a fixed frequency timer such as ACPI or HPET.
DMI Frequency: Better known as bus frequency is the BCLK on Intel platforms and HTT on AMD platforms. It’s a fixed frequency that can be changed in the BIOS or on the fly in Windows.
On Windows 8 + Intel, the RTC and QPC use the DMI Frequency, hence we get the time continuity error.
On Windows 8 + AMD, the QPC uses the DMI at stock frequency and the HPET at modified frequency.
On Windows 8 + Intel after Win8 installed on AMD: QPC uses HPET, thus no error! (AMD has fixed Intel?)
(When HPET is not available, the ACPI timer is used.)
So what is the difference?
Christian has found that installing Win8 on AMD means that one additional parameter is enabled: ‘useplatformclock’.
When ‘useplatformclock’ is enabled, the QPC uses HPET, and we see no error.
When ‘useplatformclock’ is disabled, the QPC uses DMI, and we see the error.
Christian also found that this can be modified in Windows 8, under Intel or AMD, by the following:
This means AMD systems can be affected to, and should not be allowed on HWBot.
But what about Windows 7? As far as we can tell, Windows 7 does not have this sort of command within the system, so unless a user can manipulate the OS to use the DMI frequency, all should be well.
Many thanks to Christian for his detective work, as well as the guys at CPU-ID for enabling the software. Please send a few clicks over to the original article showing the evidence for this research.