Windows 8 Benchmarks Banned on HWBOT Over RTC Issue

Toggle sidebar Toggle sidebar
Status
Not open for further replies.
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.
 
@warezme

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.
 
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.
 


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.
 
It is a big issue with benchmarks, I remember with windows 2000 and older where you could change he RTC info in software. You could trick a benchmarking application into Giving you an insanely high score that would put even supercomputers to shame by making the applications think they completed a batch operation that would usually take a few minutes, in a few milliseconds.

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.
 
Intel and MS sounds like collusion to me.

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.
 
I hope this doesn't effect the audio quality over USB. Would be very unhappy for an audio sync issue for my external DAC running ASIO for 24b/192k over USB3/2. I might have to dump Win8.1 for Win7.
 
Here's my guess as to why there's a problem, for what it is worth:
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.
 
Hey, @fixxxer113, I visited a huge biofuel power plant in California that was run entirely on Windows XP. They had a couple of rack servers controlling everything... on Windows XP. So you're right. One does not simply install Windows Server to run a power plant. They use Windows Client OS. Nuclear may be a differently manage, but I was a bit bothered by my experience overall.
 

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.
 
To the guy that's uninstalling Win8 because of this, wow, really, just wow. Do you actually understand what's going on, or do you also remove your car's engine every time you hear about how it's affecting the atmosphere? Because this is far less significant than the potential carbon build up even an electric car is responsible for (before some "smart" person tries to point out electric cars are zero emission, you need to realize they still use power that comes from a plant, and the plant is likely coal/oil as Nuclear is considered dangerous, though if you are using Nuclear, then it's what it's doing to the Micro environment instead of the Macro)

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.
 


Well, I'm sure you'll find all kinds of OSs installed in all kinds of places, but the point is that the software makers themselves make it absolutely clear that it should not be used in places where health and human lives are depended on the flawless operation of software.

 
Status
Not open for further replies.

TRENDING THREADS

Latest posts

Moderators online

Share this page

COMPANY
RESOURCES
FOLLOW
Top Bottom