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."
Get Tom's Hardware's best news and in-depth reviews, straight to your inbox.
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.
Kevin Parrish has over a decade of experience as a writer, editor, and product tester. His work focused on computer hardware, networking equipment, smartphones, tablets, gaming consoles, and other internet-connected devices. His work has appeared in Tom's Hardware, Tom's Guide, Maximum PC, Digital Trends, Android Authority, How-To Geek, Lifewire, and others.
-
Estix Does Tom's have any plans to look into this? I'd love to see you guys do some testing on it :-)Reply -
warezme So how does this effect time sensitive hardware controlled by software running on this POS OS? So instead of opening a valve at exactly a certain time, it opens it 18 (or whatever) seconds later or before while some volatile material X is still in the system causing an explosion?Reply -
aicom Reply11389133 said:So how does this effect time sensitive hardware controlled by software running on this POS OS? So instead of opening a valve at exactly a certain time, it opens it 18 (or whatever) seconds later or before while some volatile material X is still in the system causing an explosion?
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. -
fixxxer113 @warezmeReply
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 :P
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. -
InvalidError Reply
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.11389133 said:So how does this effect time sensitive hardware controlled by software running on this POS OS? So instead of opening a valve at exactly a certain time, it opens it 18 (or whatever) seconds later or before while some volatile material X is still in the system causing an explosion?
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. -
DRosencraft Here's my guess on what is happening; when the under/overclock settings are loaded, and the variety of optimized programs try to check settings, it interferes with whatever software is actually managing the clock during various operations. I don't imagine this is all that huge a deal. The full report seems to suggest that it's unique to Intel processors, so perhaps this is a problem of an instruction set specific to Intel in Win 8, perhaps a power saving or performance optimization function.Reply -
jimmysmitty Reply11389133 said:So how does this effect time sensitive hardware controlled by software running on this POS OS? So instead of opening a valve at exactly a certain time, it opens it 18 (or whatever) seconds later or before while some volatile material X is still in the system causing an explosion?
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. -
back_by_demand A jug of NO2 and overclock that puppy to 8Ghz and bingo! Instant time machine! All I have to do now is memorise the lottery numbersReply -
InvalidError Reply
It isn't an instruction set problem.11389796 said:The full report seems to suggest that it's unique to Intel processors, so perhaps this is a problem of an instruction set specific to Intel in Win 8, perhaps a power saving or performance optimization function.
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.