Yesterday, popular overclocking site HWBot announced that due to problems with Windows 8′s performance when overclocking, they would no longer accept or validate results that used that platform. This was sufficient to kick off a tidal wave of speculation and vitriol towards Microsoft’s supposedly poor real-time clock (RTC). This has been picked up and magnified across the internet with all the inevitable effects of a game of telephone. It’s time to inject some sanity and examine what we
really know — and what we don’t.
This problem impacts a tiny group of people
The issue HWBot has identified
has no impact on stock hardware. It has no impact on BIOS-level overclocking. It has no impact on software multiplier adjustments. This problem is limited to software programs that adjust the base clock rate (BCLK) on-the-fly, without a reboot. I’ve talked to several boutique owners in the past and they’ve confirmed that even among computer enthusiasts, overclocking is fairly rare. Overclocking by BCLK is even rarer for multiple reasons — but mostly because Intel discourages it these days and doesn’t allow it to occur save within a very narrow range.
I’m not saying HWBot was wrong to do what they did, because when your reputation is built on validating OC results, you have to make certain the results are, well, valid. But the first thing to understand is that this problem is only going to tag a specific group of people using software to overclock within the OS.
The actual clock mechanism involved isn’t clear – but this isn’t a cheat
One thing I’ve seen mentioned at several sites is the idea that Microsoft is somehow cheating to try and make Windows 8 look better. (See:
Windows 8: The disastrous result of Microsoft’s gutless equivocation.) This betrays a fundamental lack of understanding for the problem. The fact that the system clock is losing time rapidly is proof that this isn’t intentional. Keeping system clocks updated and synchronized can be extremely important across a network. A system losing 18 seconds out of every 5 minutes will be nearly 6 hours out of sync within four days. That means backup jobs and system maintenance normally scheduled for 04:00 is happening at 10:00 instead. This is a real problem.
But the repeated references to Windows RTC (real-time clock) probably aren’t accurate. Previous versions of 3DMark (a program affected by this errata) have all relied on HPET,
not RTC. HPET was introduced in Windows Vista; it polls at 14MHz rather than 3.2MHz and was required for running 3DMark 11. It’s highly unlikely that Futuremark returned to using the old RTC rather than the newer HPET standard.
I’m going to use a metronome analogy to explain the problem here. At boot, the system “calibrates” its internal metronome at a given speed — let’s call it 133 beats per second. Right now, changing the BCLK value in software is simultaneously recalibrating the metronome. Set the system to a BCLK of 122, and then run a benchmark, and the system reports a lower time in seconds. The system clock is falling behind the objective wall time because each second is fractionally longer than it ought to be.
I think this problem would have been clearer if HWBot had added a column to the chart above. The
wall time required to run these tests should be identical in both cases. What’s happening here is that the system’s counters are shifting the number of beats per second, rather than keeping that figure constant. I suspect this problem might be fixed by flipping a deep setting in Windows 8 to adjust how it handles this kind of on-the-fly adjustment — which leads us to the next point.
OS-level overclocking software has always been hit-and-miss
I first cut my teeth on overclocking with an IBM PC, a K6-233, and a Golden Orb. The K6-233 was swapped out for a K6-2 400 thanks a 2x/6x multiplier remap that could be swapped via hardware jumper on the motherboard. Then the first K6-2+ came along: 500MHz on .18 micron with an on-board L2 cache. I picked up an MSI-5169 motherboard, overclocked the chip to ~580MHz, and was off to the races. For all the changes between then and now, one thing has remained constant: Overclocking tuning software run
within the operating system has almost always sucked.
I’m not saying this to excuse whatever is going on with
Windows 8, because clearly that problem is OS-wide. Back then, we fought for BIOS-level tools precisely because software was so hit and miss. It was not unusual for a motherboard manufacturer’s tool to insist a system was running at one speed while third-party tools implied another and benchmarks indicated a third. The experience has improved modestly since, thanks to various motherboard tools and support from Intel and AMD, but Intel’s own Extreme Tuning Utility requires you to reboot if you want to change the base clock — and it alters the value passed to the BIOS for boot initialization. I suspect that’s to avoid this kind of problem.
The point here is not to give Windows 8 a free pass, but to acknowledge that problems with software OCing have plagued operating systems for as long as there have
been operating systems. Some components have never liked on-the-fly adjustments of their frequencies. Some programs don’t respond well to this kind of shift.
The ball, so to speak, is definitely in Microsoft’s court on this one. The timer behavior is unusual and likely unintentional. But this is a problem that will impact a fraction of overclockers, which are a fraction of hardcore computer enthusiasts, who are a fraction of computer
users. It’s not unusual for programs that change timings post-boot to create erratic behavior as a side effect. The real problem is the way the internal clock gets knocked off kilter — and that’s something MS can almost certainly fix.
Quote
