Overclocking, what do you like for stability test?

Luck100

Basically, finding stable overclocks is very tedious. The usual recommendation for testing your CPU overclock is to run prime95 or burntest. They can take hours to find unstable overclocks.

By accident I discovered yesterday that Unigine Valley is much quicker for me - it blows up within seconds or a couple of minutes on unstable overclocks that take forever with the others. And yes, I'm talking about CPU overclocking. And, being a gpu benchmark, valley is also good for testing gpu overclocks too.

Anybody else try this? Or have some other way to test? I've heard of Aida but it's not free.

The strange part is that Valley doesn't seem to run the cpu nearly as hard as prime95 or burntest, at least judging from cpu temperature. It must be doing something else that catches out too-low vcore levels.

marco_polo

Luck100 wrote: »

Basically, finding stable overclocks is very tedious. The usual recommendation for testing your CPU overclock is to run prime95 or burntest. They can take hours to find unstable overclocks.

By accident I discovered yesterday that Unigine Valley is much quicker for me - it blows up within seconds or a couple of minutes on unstable overclocks that take forever with the others. And yes, I'm talking about CPU overclocking. And, being a gpu benchmark, valley is also good for testing gpu overclocks too.

Anybody else try this? Or have some other way to test? I've heard of Aida but it's not free.

The strange part is that Valley doesn't seem to run the cpu nearly as hard as prime95 or burntest, at least judging from cpu temperature. It must be doing something else that catches out too-low vcore levels.

It could just as easily be finding memory controller/NB instabilities. The purpose of SmallFFT in prime 95 or other burn tests is soley test just your CPU core stability and nothing else.

Running something like Valley, (or Large FFTs) you are throwing the L3 cache, NB, memory controller and RAM into the mix as well, so a crash is just telling you your system is unstable, but is not particularly useful in narrowing it down further as there are so many variables in play. The fact that it is crashing despite not pushing the CPU as hard as the burn test strongly suggests that it is not core stability but something else as the root cause.

CrinkElite

Yeah, I'd have thought the same.
You could try downclocking the memory and running Prime95 again.
You may find a stable overclock higher than what you thought possible.

Luck100

@marco_polo, that makes a lot of sense. Thing is, I'm running my tests with valley totally stock except for cpu multiplier and vcore offset. At fixed cpu multiplier, I'm bumping the vcore offset up in steps until valley becomes stable. So even if it is some other component that's causing instability, it's happening as I adjust vcore.

No memory overclock, no other settings changed.

Luck100

@CrinkElite, memory's not overclocked. It's running stock at 1333 MHz. I'm only overclocking the cpu.

Generally I seem to be stable in prime95 at lower vcore offset, at least with only a few minutes testing. Could quite possibly be unstable with hours of testing. But Valley blows up very quickly at the same vcores where prime95 seems stable .

game4it70

Unfortunately there really is no quick way to find a stable OC.In saying that peoples perception of "stable" varies so much.I've had prime blue screen me 11 hours into a test which was a right pain but thats the type of "stable" i go for.

I tend to use Prime,Xtu,x264 and Ibt but in general i've found Prime to be best at finding fault with the OC i'm trying for.
Another great thing i found was battlefield 3.If i could play a few hours of that without a crash i knew i was almost sure of a stable OC.Bf4 is just broken so can't use that to test which is a shame.

Luck100

@game4it70, I agree there is no quick way to find a true stable overclock. I just find my unstable overclocks more quickly with Valley. Since Valley crashes much more quickly than prime or burntest, seems like I'd rather crash with Valley in 90 seconds than prime after 6 hours. Once I (quickly) get a vcore which works with valley, then I can let prime/burntest grind away for hours to double check.

Of course, it might be some other component which is unstable in Valley and not the cpu. But if that's the case, it's happening with all settings at stock (other than cpu multiplier and vcore). The crashes in Valley are quite sensitive to vcore. I go from crashing in seconds to stable for long periods with only another 0.01 volts offset.

marco_polo

I haven't played around much with Intel overclocking as I have been on AM3 for a good few year (I got an i5-2500k recently but it is still at stock).

I do remember my old Phenom II used to pass SmallFTT with ease, but crashing almost instantly for LargeFFT or blend, in my case it was IMC stability and took a good bit of tweaking CPU-NB voltages/NB and HT link Frequeies etc to get it working 100% (All of these things have completely different names in an Intel bios ).

From what I can see the IMC/NB of Intel plaforms seems alot more stable in this regard, so from the looks of it people can mostly achieve very good clocks without ever going near anything bar the multiplier and a handful of CPU settings, so it doesn't seem as likely to be your problem.

Interestingly this guy has posted a blog about something similar so perhaps there is something to it. I can't say I am 100% convinced but I guess it is plausible that the increased the load on other parts of the chip (other than the L1+L2 caches and cores stressed during smallFFT), might be introducing slight instabilities.

http://blog.szynalski.com/2012/11/25/the-right-way-to-stress-test-an-overclocked-pc/

Luck100

I think I have this figured out now. I was using offset voltage - not a good idea for stability testing. I went to fixed voltage with turbo LLC and now things are making more sense. Once I get to a stable voltage with prime95, Valley is stable too. Even at slightly less voltage, where prime is not stable, valley still runs ok.

I guess with offset voltage, I was getting enough voltage at peak load (so prime was stable) but not enough at partial load (so valley was crashing quickly). With fixed voltage that obviously can't happen, since the voltage actually goes up slightly with less load (due to decreasing droop at lower loads).

I'd still like to use offset mode eventually (once I have stable voltages sorted). I think the key is to use a lower LLC setting while bumping up the offset to make sure peak load voltage is hitting the required value for stability in prime. With lower LLC there should be less of a voltage drop-off when going down to medium or low load (which is where I was crashing before).

BloodBath

Yep LLC is important to counteract Vdroop. You have it sussed. I wouldn't worry about running benchmarks for hours on end.

If it's stable after 15 mins I'm happy. I'll test proper stability myself by using the pc.

Luck100

Yes, I was just happy to see no blue screen for 30 minutes. I don't really see the point of 12 hour tests myself. If I want to be sure ultra-sure I'm stable I can just bump up by another 5-10 millivolts.

The thing that got me was that too much LLC was actually causing problems in offset mode. LLC stops the droop, but it also means that the idle and low load voltages have a bigger voltage drop-off from peak. That's what was blowing me up in Valley.