Windows 8 Benchmarks Banned on HWBOT Over RTC Issue
There's a problem with Windows 8's real-time clock that affects all benchmarking tools.
HWBOT said on Monday that it is no longer accepting Windows 8 benchmark records due to, according to the site, severe validity problems with the Windows 8 real time clock (RTC). All existing Windows 8 benchmarks will be disqualified as well as new ones submitted to the popular benchmarking database.
The real-time clock is typically on a hardware level, residing in the motherboard's southbridge and feeding off a button battery just in case something happens to the power. Thus unlike software clocks which can be easily changed manually or altered by other software, this one silently keeps track of the proper time, even when the computer is shut down. Benchmark tools typically rely on this hardware clock to report exactly when the benchmark started and finished.
However for Windows 8, the platform features a real-time clock that accommodates embedded or low-cost devices that do not have a hardware-based clock, thus its timekeeping routines are a little different thanks to the platform's "one OS to rule them all" scenario. The site doesn't go into detailed specifics, but instead reports that when the CPU base clock (BCLK) frequency in software is changed (not at boot), it has a huge effect on Windows 8's ability to keep proper time.
As an example, the site used a Haswell test system and downclocked the BCLK frequency by about 6 percent from 130 MHz to 122 MHz. Using a CPU ratio of respectively 32x and 34x, the resulting CPU frequency remained 4160 MHz. Eventually it was determined that Windows 8 had actually lost 18 seconds over a five minute period; when overclocked, Windows 8 was 18 seconds quicker. Overclock roughly 4 percent, and after two minutes, Windows Time was three seconds ahead of real time.
"At the moment of writing, we do not have the full technical what’s and how’s figured out," the site states. "Since this problem affects everyone who is passionate about overclocking, it is important to provide an explanation. It is far from the complete story, but it should be enough for you to understand why we have decided to ban Windows 8 from HWBOT."
Having a device's timer line up with the real world time ensures that applications such as benchmarks and even alarm clocks produce accurate measurements, predictions and results. Benchmarks assume that the local RTC is accurate and functioning correctly. As it stands now, running a five-minute benchmark on an underclocked Windows 8 device means the process will actually take five minutes and eighteen seconds, or six percent longer. Boost the multiplier to compensate for the lower BCLK, and the device draws 6 percent more frames, or completes six percent more floating point calculations, thus generating a 6 percent higher score.
"It is not possible for HWBOT to accept any benchmark results or records achieved using Windows 8," the site states. "Simply no benchmark – not even 3DMark – is unaffected by Microsoft’s RTC design decisions. As a result, it is impossible to verify the veracity of a system performance indicative in Windows 8. The resulting score of any benchmark is relative to the RTC bias of that system."
For now, HWBOT will block any seemingly out-of-line Windows 8-based benchmark results. It will also block any Windows8-based benchmark record, even if the score seems in line with the expectations. For more information, read the full report here.
I would hope that someone running a critical system would not be doing BCLK overclocking under any circumstances, let alone while the system was running.
I would hope that someone running a critical system would not be doing BCLK overclocking under any circumstances, let alone while the system was running.
Usually, commercially available software - especially at the consumer level - contains clauses in its EULA stating that the software is not suitable for these kinds of critical applications. One does not simply install Windows Server to run a nuclear facility
Below is an example of a clause from Microsoft's SPLA agreement, which btw is far from consumer-level. It's a contract for service providers, who usually own large datacenters with lots of failsafes. Even so, the contract states:
"No High Risk Use. The software is not fault-tolerant and is not guaranteed to be error free or to operate uninterrupted. You must not grant the right to use the software in any application or situation where the software failure could lead to death or serious bodily injury of any person, or to severe physical or environmental damage (“High Risk Use”). Examples of High Risk Use include, but are not limited to: aircraft or other modes of human mass transportation, nuclear or chemical facilities, life support systems, implantable medical equipment, motor vehicles, or weaponry systems. High Risk Use does not include utilization of software for administrative purposes, to store configuration data, engineering and/or configuration tools, or other non-control applications, the failure of which would not result in death, personal injury, or severe physical or environmental damage. These non-controlling applications may communicate with the applications that perform the control, but must not be directly or indirectly responsible for the control function. You agree to indemnify and hold harmless Microsoft from any third-party claim arising out of end users’ use of the software in connection with any High Risk Use."
So, specialized and critical applications will have specialized software, or heavily modified versions of off-the-shelf software (eg. Microsoft software licenses for military use etc.).
Nevertheless, a problem with timing is a major issue for all users (especially in networks) and should be adressed by Microsoft ASAP. Issues in timing and RTC can have a negative effect in all sorts of applications. Maybe not enough to destroy the world, but certainly enough to cause people and businesses to lose time and money.
What sort of idiot overclocks a mission-CRITICAL system? You would likely get investigated for criminal negligence or worse should anything go wrong and your system might be indirectly partly responsible for it.
And if you are mixing volatile substance, I would hope you use weight, volume, flow-rate or other similar measurement rather than plain timing. If all the flow rates are calculated on the same system, they all have the same timing error on them and proportions would be preserved regardless of clock error give or take a (usually) small error due to deviation from calibration tables.
For one, 8 is not a POS system. People seem to think that and probably never have even used it or if they did just can't adapt to the new interface.
As for the issue, this wont affect major systems as anyone who is using any sort of system to control anything use Windows Server and Server is not just a cut down version of desktop OS. It is its own OS.
The local waste management here had us build them a server to run their facility and it had Windows Server 2008 R2 installed, not 7.
This really will only affect systems that have overclocking and may just affect certain setups such as Haswell that has a BCLK or SB-E/IB-E since they also have a BCLK and remember how the BCLK does affect other parts of the system. I would like to see this done with a stock BCLK and a higher multiplier and see if it affects it the same way.
If not then we know its an issue with Windows 8s RTC that needs to be, and probably will be, addressed and fixed to not rely on a BCLK setting. If it still does it then it may be another issue but still for important things its not an issue. Its just for us enthusiasts and review sites.
It isn't an instruction set problem.
A common power-management tweak on low-power-optimized platforms is to ditch real-time clock interrupts and try to group non-time-critical interrupts in one CPU wake-up round instead of waking up the CPU hundreds of times per seconds to do "++time" and little else.
The upshot from that is the OS needs to rely on some form of timer-counter to figure out how much real-time passed by while the CPU was sleeping. I'm guessing Intel's counter is tied to BCLK and someone forgot to compensate for that somewhere.
For OS such as windows xp, vista, and 7, you can feed applications with false rtc info and it will at most lower your benchmark scores.
While it is unlikely for anyone to believe that a CPU such as a core i5 will get a billion points for the CPU score,It is not beyond a user to use a memory editor to change the detected specs to show a new overclocking record, then feed cause some high scores which will scale perfectly since they will be changing the 1 value the app uses when calculating the scores for all aspects to match, thus everything looks in line and a user with a stock system is topping the benchmarking charts.
This of course mean all of tom's reviews with Intel and Win 8 are suspect especially the overclocking results.
It could just be MS exploiting an Intel method to boost OC numbers, but are they sure it has no effect on stock settings?
Don't say they just miscalculated this, were talking about the big boys here.
I just don't buy the it's because of one size fits all, the OS detects the device its running on.
it would explain the irregularities Toms has been seeing in test results. wink.
On AMD platforms, Microsoft knew that the BCLK equivalent was widely variable, so they didn't trust it – they used something else.
On Intel platforms, they were highly negligent and, based on the fact that since SB the BCLK has been kind-of locked, wrongly decided that it would be constant – and used that somehow.
Audio does not rely on RTC interrupts. They usually rely on DMA buffer queues with one block being DMA'd to the sound chip while the others are being filled by software.
Seriously, while I have three Windows 8 machine running on Intel chips, I have no intention of changing anything for this. This might even be why it seems like my system clock is slightly off on my media PC but from the article it's unlikely as that system is not overclocked and this only affects machines that are modified while running.
How has this impacted my (OC) 4.6 GHz Sandy Bridge i7? None, it plays games just fine. I don't use it for critical tasks (though I know some people consider gaming critical). It doesn't BSOD (though Win8 has the best BSOD of all Windows versions, seriously, look it up) it doesn't stop running, and games most certainly don't notice even when I do modify the Core Clock and Multiplies through the neat tools that Gigabyte included with my Mother Board.
People that legitimately should uninstall Win 8 are those seeking glory for having the fastest rig and post results to HWBOT as they are no longer valid. Unless you do that, or something similar, then worrying about this seriously insignificant issue is just more BS over-reaction to an operating system that a lot of people don't like.
_WAter_
Not just overclock. You also need to mess with BCLK on-the-fly from the OS which is somewhat unusual even for overclockers.
You boot with BCLK at 130MHz with 32X CPU multiplier, Windows calibrates its time-keeping based on 130MHz BCLK, then you switch to 122MHz BCLK with 34X CPU multiplier. Now, the hardware counter that keeps time sees 122M ticks per second instead of the 130M Windows is expecting and real-time as calculated by the OS gets compressed by 6% (~1.06 real-time seconds for each second Windows thinks passed by) because Windows is still counting time assuming the BCLK is still 130MHz.
Intel probably needs to update its CPU/chipset driver to intercept writes to registers that control BCLK and update the time-keeping counter's clock-divider to offset the change.