I have been seeing random mentions on the web about this and really didn't think much of it. The web is full of BS sometimes as we all know. So finally, I ran across a post from a knowledgeable and respected person (Raja @ ASUS), that seems to explain why we should not be using it to test Haswell CPU's. Here is the snippet...
Do we agree with this assesment? I know personally I have stress tested multiple haswell and one haswell E CPU with the latest P95 with no ill effects at both stock and heavily overclocked settings for hours.
Do we agree with this assesment? I know personally I have stress tested multiple haswell and one haswell E CPU with the latest P95 with no ill effects at both stock and heavily overclocked settings for hours.
http://www.overclock.net/t/1510388/haswell-e-overclock-leaderboard-owners-club/2390#post_22900116Praz 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.
-Raja