Originally Posted by Mydog
I totally agree but I still see people who claims the OC isn't stable before it can run for XX hours on Prime or IBT etc and no other benchmarks can get the CPU hotter therefor stress the CPU better which to me is nonsense. I don't have the technical knowledge to explain why using those kind of software are no good.
Praz nailed it really. The newer versions of Prime load in a way that they are only safe to run at near stock settings. The server processors actually downclock when AVX2 is detected to retain their TDP rating. On the desktop we're free to play and the thing most people don't know is how much current these routines can generate. It can be lethal for a CPU to see that level of current for prolonged periods.
As for the universal validity of various stability testing programs, that's a more difficult question to answer without using illustrations to simplify what occurs at the electrical level on some of the associated buses.
Being brief as possible and focusing on DRAM transfer as an example: Data is moved around the system in high and low logic or signal states. The timing of these systems and those that rely on them needs to be matched closely enough for data to be moved around and interpreted correctly.A burst of data may contain a series of 1s and 0s. The 1s pull more current as they require defined voltage level that is above 0. Each data pattern has a different effect on the timing margin. Some eat into the timing margin more than others (I may illustrate the theory of this in a future guide). If a given stress test does not generate patterns in a way that eats into the timing budget sufficiently to represent how the system is used, the stress test won't be as useful to the end-user.
That's why most stress test programs alternate between different data pattern types. Depending on how effective the rotation is, and how well that pattern causes issues for the system timing margin, it will, or will not, catch potential for instability. So it's wise not to hang one's hat on a single test type. Evaluate what your needs are from the system and try to run a variety of tools to ensure the system is stable in various ways. We also need to bear in mind that some stress tests only focus on a single part of the system, while others will impact multiple areas at once.
Seasoned users usually find a systematic way that leads them from stress tests that focus on individual areas to those that hit the entire system as part of their test regimen. Ultimately, this all comes down to what your requirements are and using enough testing to confirm reasonable stability for the system in its intended usage scenario.
We coded Realbench to generate stress with real-world apps. It's a useful tool for people that encode, render or crunch numbers with their systems. However, it's not the only method out there - there are many tools to evaluate system stability that are perfectly valid.
-RajaEdited by Raja@ASUS - 9/24/14 at 7:40am