Any stability tests that don't heat up the CPU?

[BTRY B 529th FA BN]

x264 stability test. I have had overclocks which passed 100-passes of Intel Burn Test + a couple of hours of Prime95 (SSE2 version), but failed the x264 test.
This correlated with those overclocks BSODing during Handbrake encodes.

Does not raise core temps nearly as much as either IBT or P95 :

http://www.overclock.net/t/1487922/going-deeper-on-the-x264-v2-stress-test

What do I need to run x264? I've downloaded the files, unpacked them. Not sure exactly what to do with it.

Thanks for the help so far

 

[coffeemonster]

x264 stability test. I have had overclocks which passed 100-passes of Intel Burn Test + a couple of hours of Prime95 (SSE2 version), but failed the x264 test.
This correlated with those overclocks BSODing during Handbrake encodes.

Does not raise core temps nearly as much as either IBT or P95 :

http://www.overclock.net/t/1487922/going-deeper-on-the-x264-v2-stress-test

+1
I don't even bother with P95 anymore and just use handbrake x264 encodes. It's the most work I ever put on the CPU anyway.

 

[Ketchup]

The latest 3dmark does not get my cpu nearly as hot as the latest prime, but that doesn't mean I would run at a speed that couldn't psss the latter.

 

[Techhog]

That's almost like asking "any fake stability tests out there?"

Any "stability" test is going to put load on the CPU which means heat.

If your criteria is "my games don't heat it up that much so I have no reason to test that way" then run your games and see if they crash. Doesn't mean your CPU is "stable" but if that's all you're concerned with than maybe it's stable enough for you. There's obviously no guarantee that you're going to be able to avoid silent data corruption.

No stability test can guarantee that though

 

[2is]

No stability test can guarantee that though

Perhaps not "guarantee" in it's strictest sense, but you're certainly increasing your risk by quite a bit if your stress tests aren't actually stressing. That's like saying you want to get in better shape by doing what you normally do.

 

[WhoBeDaPlaya]

Stress testing done right takes a while, there is no shortcuts here, but the endgame is worth it, specially if you are of the tinker type (I would consider anyone going for a X5690 at this point to fall under this category). GL :biggrin:

Just got a dual X5675 system

 

[WhoBeDaPlaya]

What do I need to run x264? I've downloaded the files, unpacked them. Not sure exactly what to do with it.

Thanks for the help so far

There are a couple of batch files in there :
x264 Stability Test (32bit - log)
x264 Stability Test (32bit + log)
x264 Stability Test (64bit - log)
x264 Stability Test (64bit + log)

Just execute the appropriate one, enter the number of loops, set the number of threads, set the priority, and you're off to the races

Now you can test using a Handbrake nightly build and x265. x265 algorithms are way more computationally complex than x264. Encoding will use AVX2 heavily if your CPU supports it. Takes forever, though, so use a short AVC video clip if you're just testing for stability.

Too lazy, I'll just wait until they package up a nice bundle like the current x264 stability test

 

[FlanK3r]

Very good, as people mention, are x264 test and y-cruncher for classic stability. The ycruncher test for 500m or more is very good for calculations issues

 

[DrMrLordX]

I like y-cruncher, but it does get my CPU warm. For anyone with a Haswell, y-cruncher will bring even more heat (AVX2).

 

[BTRY B 529th FA BN]

There are a couple of batch files in there :
x264 Stability Test (32bit - log)
x264 Stability Test (32bit + log)
x264 Stability Test (64bit - log)
x264 Stability Test (64bit + log)

Just execute the appropriate one, enter the number of loops, set the number of threads, set the priority, and you're off to the races

Cool! Thanks

I only have SSD drives in the machine I was thinking of testing. Do you think it's worth the little bit of trouble to drop in one of these two HDDs sitting besides me for the test? If so how would I dedicate the test to be ran on the HDD? Just run it from the HDD?

 

[BonzaiDuck]

Cool! Thanks

I only have SSD drives in the machine I was thinking of testing. Do you think it's worth the little bit of trouble to drop in one of these two HDDs sitting besides me for the test? If so how would I dedicate the test to be ran on the HDD? Just run it from the HDD?

I had some more general questions and remarks which I'll add after these.

I don't think it matters which storage device you use, but it DOES matter that you don't corrupt a good OS installation while stress-testing. And while I'd recommend doing stress-tests on a cloned OS drive (of either type), I'd only take the trouble to do it within a month after building the new rig. And to be honest, since at that stage it's easy to reinstall an OS with no other software but stress-programs to reinstall, I probably don't bother anyway. But also -- would you allocate money for a spare SSD in this scenario, when you could use an old but functional HDD? If the HDD OS installation survives, gets a clean bill of health running SFC /SCANNOW and CHKDSK, you could simply clone it to a fresh SSD.

About this matter of heat and stress-test programs.

I've taken to using OCCT as only part of a battery of tests. I fully realize what some other said here -- that even the most brutal stress tests may not reflect a variable real-world usage or that it's a good idea to use some representation of the latter before you pronounce rock-solid stability.

Further, other issues can pop up. It is possible to get seeming stellar stress-test results, but the system shows instability while idling. This, too, can be corrected. But suppose the instability only shows itself infrequently? Worse than that, there are "false-positives" where something else other than clock settings causes instability. For instance, I think there are enough folks here who might agree with me as to a suspicion or conclusion that using more than one sensor-monitoring program at once can lead to these false positives.

Back to OCCT. It includes its own CPU test along with a built-in LinPack implementation. The author argues that it will reveal instability or errors sooner than hotter-running stressers like LinPack or Prime95, but the processor may not reach above 5C to 8C BELOW the temperatures you'd find with LinPack. So it will run cooler; but reveal errors or instability faster.

I think I've verified this several times. My system could get through 15 or even 20 interations of LinX, but fail the OCCT:CPU test within the recommended three hours. Yet LinX or IBT would really "put a burn" on the processor in comparison.

So I use OCCT runs together with LinX, IBT and Prime95. I attempt to reduce the length of overall stress-testing -- to reduce any likely degradation to my patience and the risk of degradation to the processor.

If it passes 3.5 hours with OCCT, I might try 25 passes at IBT, and ultimately 50 passes with affinitized LinX. After that, I might make some tests of 10 or 15 iterations of LinX and collect "small-sample" data on GFLOPS to see if some minor tweaks can reduce the range or variation (read "standard error" or "variance") without unnecessary over-volting.

Under that same regimen, I might use Prime95 SFFT and LFFT here and there, but I never feel compelled to let the test continue beyond 5 hours or so.

If something "turns up" -- say -- a perception that there's a problem with RAM or IMC voltage, I might pick an appropriate test that fails, make some tweaks, and run it again until it passes.

But the OCCT experience makes me think that you do not need to set fire to the processor during the stress-tests to find a problem. Nor do you need to use tests with the AVX2 instruction set overworked to death -- when that is never going to happen in the real-world.