OC Stability Testing Programs (Prime, Linx, IBT, Aida64...)

[Tiporaro]

**Sorry in advance for the long-winded post**

So, while there's been discussion sparsed throughout various threads I was hoping to have a little bit of feedback consolidated here and get some ideas on what people think actually is a fair judge of stability (if this has already been hit, I apologize, but I didn't see quite what I was looking for in a quick search).

Prime95 - what we've all been used to
Specifically, I've been used to using prime95 in the past as a go-to stability test. While that still seems like it works, I definitely have run into some situations where, for maybe a few reasons, prime doesn't seem the best indicator of a stable system. Namely, I've seen instances of prime requiring significantly more voltage (~.04-.05v) to prevent one worker from stopping than what any other benchmark or everyday stability would require. Yes, I know - the traditional thought is that a stopped worker simply means you're not at that stability point yet. However, I don't feel like its as spot on as it was in the past in so far as defining when you've hit stable for everything outside of prime itself.

Add to that the fact that on multiple sandy bridge (2600k) oc's that I've played with recently, the idea of using voltage/speed ramping (speedstep/C1E) is actually viable and appealing. For whatever reason, prime95 will pull on average ~.02v less than what other stress testing benches pull under load (tested both on asus and gigabyte boards, but maybe this result is different elsewhere). Whereas I can have real world use (encoding, gaming, etc.) as well as other stress tests run solid with voltage ramping up to a consistent level, prime95 doesn't pull the same amount and inevitably fails.

This has led me to looking at other modes of stress testing as my go-to bench - the ones I see the most tossed around after prime without going into more graphics related stressing are IBT, linX, OCCT (which i believe incorporates linX or is very similar at least), and Aida64. If there are others that people have put consistent faith in, please jump in!

IBT
Now, among these, I haven't used IBT that much recently as I remembered it being one of the more generous stress tests that would pass when a system wasn't quite there yet. While that doesn't mean IBT isn't worthwhile, in the past I had jumped over IBT in favor of prime.

Linx/OCCT
As for, linx (and OCCT linpack?), linx always seemed to be a little over-aggressive - it pushed a lot synthetically and really threw a lot of heat at your cooling system. And typically that meant that if your oc survived linx, you were golden. However, I kind of felt that if you were stressing it for only the point of being able to run that one stress test that isn't as helpful as it could be. Specifically, if no real world stress on the cpu (something that pegged all cores as much as possible, but was actually a real application) could cause a failure, I would consider that to be a successful OC.

***Yes - I appreciate the fact that stress testing reveals flaws that might not be seen empirically in everyday use - this discussion is more focused at whether some synthetic benches may go *too* far, which has been brought up I believe by others recently.

AIDA64
I also recently started trying out AIDA64, and using the more balanced stress test including the memory, not just the cpu and/or cache. From my limited experiences using AIDA64 only on the P67 platform, a long term stress run of this type has been spot on to finding real world stability. If I drop the memory stress in aida and go just for cpu and/or cache stressing, this seems to give me a thermal testing equivalent to linx.

To put this in context, my own rig right now is running a 2600k @ 5ghz at 1.41v, with speedstep and c1e pulling it down to idle slightly over 1v. Idle is around 28C, typical loads in real world use stay in low 50's. Empirically, this has not crashed since I finally dialed the OC in with speedstep active a few weeks ago.

Further, I can run full 24h of AIDA64 "balanced" stressing with the cores right around 70C, which I consider to be more than adequate. Linx and AIDA64 cpu/cache only will push the thermal envelope up to ~80C, which I would consider to be high for anything other than those tests in particular - however, I still pass those tests stable, albeit hot. Prime however doesn't want to let the first core go for very long before stopping, and I believe there is some issue that has the voltage running just a little lower and preventing stability. As I mentioned earlier though, even with manually hard set voltage, prime wants more voltage than *anything* else.

This brings me to asking - has anyone else had any weird occurrences with prime, or have decided to move on from it? Does anyone's experience with AIDA64 mirror my own? Linx? I basically would like to reach the point where I can once again put faith in a stress test in particular as being very representative of whether a oc is stable (and not over-volted for no reason other than to satisfy a quirky or too synthetic bench). Yes, its never a bad thing to have multiple stress tests to fall back on, but there's always one that will be the "go-to."


TLDR - Prime95 still as good under Sandy Bridge/speedstep settings? What stress test is best indicator of actual stability, without "overdoing" it?

 

[Makeroflostsouls]

Yea I would like to know thoughts on this also. IBT will pass 20 times but prime95 was only like 30 mintues stable on my 2600k. Heck it would BSOD on world of warcraft on what IBT passed. So far I have only gotten Prime 18 hours stable. 8 of those hours I was gamming at the same time no issues. So if there is somthing better to test with i'm all ears also.

 

[Silent Knight]

To Sandy Bridge users:Have you upgraded LinX with the lastest Linpack library (which supports AVX)?It'll push the CPU further than the old LinX and might detect more flaws in your overclocking.

 

[old skool]

I'm a programmer and noticed none of the stress testers were loading the CPU to its maximum potentional back in the ol' Athlon XP days. So I wrote my own little stress tester called Toast which was specifically targeted at the K8 pipeline-- written in assembly language, I tuned the stresser to issue 3 instructions per clock cycle sustainted. It worked like a charm and beat out any stress tester in terms of how much load it put on the CPU.

Two years ago I updated it to support Core 2-- a different microarchitecture that required a different mix of instructions to achieve 3 instructions per clock cycle. Also, I wanted a one-click application that would spawn all the worker threads corresponding to the number of cores so I could test quickly. I was pleased with the result-- no other stress tester can crash a flakey overclock as quickly as mine could but everyone said its too stressful and doesn't represent a real-world application. But isn't that the point of a stress tester? I think they use this excuse after my program crashed their overclock to justify keeping the un-stable clock speed simply because lesser stress testers and normal applications don't usually crash the computer anyway.

My opinion on the subject-- its a free market and if we're going to compete in the world of stress testers, shouldn't we (the developers) update our stress testers to target new pipelines and instruction sets with a goal of getting as close to theoretical performance as possible? I've gotten a bad rap for writing a stress tester that's too stressful. Go figure THAT one out (maybe its because the capaciters on few motherboards died but honestly who's fault is that? /cough China)


You can try it out for yourself if you'd like

 

[Tiporaro]

....
....My opinion on the subject-- its a free market and if we're going to compete in the world of stress testers, shouldn't we (the developers) update our stress testers to target new pipelines and instruction sets with a goal of getting as close to theoretical performance as possible? I've gotten a bad rap for writing a stress tester that's too stressful. Go figure THAT one out (maybe its because the capaciters on few motherboards died but honestly who's fault is that? /cough China).[/URL]

I guess this is kind of where my questioning of our current stress testing is, though. Its been remarked lately that stress benches like furmark are intriguing and for sure can push things to the limits, but the value of such testing i think has come into question. There's no doubt that if your system stays stable with the most contrived and unrealistic synthetic bench, then it would definitely be stable for everyday loading. However, I think what the catch is, is that shouldn't the stress testing still be in the realm of what "real" applications can do?

Now, of course the basis of any stress testing is to reveal instability in a system that may otherwise take countless hours (if not days) to show up in normal, real-world loading of the cores. For example, lets say your system is arbitrarily 99% stable and this may result in a seemingly random crash for your daily computing every 1-2 days. You obviously want to eliminate this, and so you use stress testing that will push the system to a full load continuously, hopefully showing any issues in a much shorter time period.

When the loading far exceeds what would ever be possible in any application OTHER than the stress test itself, however, are we still even doing something truly useful? That is to say that, if we had a theoretically 100% stable machine for all of your normal full loading in real applications - encoding, rendering, folding, gaming, etc. - everything one could ever use a computer for was theoretically 100% stable with no crashes - what is the point in a stress test that stresses at say 200% of that? Sure, putting some overhead may be reasonable to just give a cushion and show problems faster, but isn't there a line to be drawn where its not representative of the actual tuned point of stability anymore?

Of course, the counter-argument to this is that, "well, if its stable under those extreme conditions, you're not going to have any problems at all - win/win!" The reply, I believe, is that a reasonable person doing an oc does NOT want to juice their processor with unnecessary volts. Of course they want a system to be truly stable. But if you were to rely on overzealous stress testing, you'd see either too much voltage being used for any given overclock, or for a higher overclock to be made unattainable/unreasonable because of the too high of voltage needed to get there.

All that being said, I don't disagree that our testing shouldn't be updated to take advantage of new architectures and pipelines as mentioned. Just questioning how far pushing synthetic benching is still a useful/accurate tool. Bringing this back to the main topic, then, is which stress bench best pushes a system so that it is simply accelerating the time between crashes/showings of instabilities that are already there, without potentially introducing instabilities that would never be there but for the stress test itself. Perhaps none cross that line in the cpu realm like many claim furmark does, but maybe some do? I personally haven't seen something real-world load a system like linX can, and have to question if this is pushing the synthetic threshold or not.

 

[BababooeyHTJ]

One thing that I really like about prime is that if you fail 10 minutes in to a test when you run the test again with the same settings if you don't make any changes in bios you will probably fail 10 minutes into the test the next time that you run it. This can really help when tweaking an overclock.

One other big plus to prime is that it is highly customizable.

I still like Linpack since it's pretty stressful and produces a ton of heat. If you are Linpack stable odds are you are in the ballpark.

 

[Tiporaro]

The one thing I question will linpack/linX is whether thermal induced failures there are accurately representative of system instability.

This is my take on things-
There really are 2 primary failure modes of an oc that lead to instability: the capability of the chip (and mb to some extent), and the thermal load. While related, I think you can get failures from either side independently. The capability aspect is whether the chip can be stable under a given multiplier/bclk/voltage etc, whereas thermal failure might have a chip that is otherwise capable but simply the temperature alone leads to a crash.

While I use linX plenty and don't doubt it's ability to test a CPU oc for it's raw capability, I have always wondered if there were thermally induced instabilities that are not realistic. I have not found or heard of a real application, even at continuous and extended load,that generates anywhere near the thermal loading that linX can. My concern is that an otherwise stable oc may be crashed in linX solely due to excessive heat not representative of anything real, and potentially past the point of saying that it is just more quickly revealing minor problems in the oc.

 

[shauntx]

I only use LinX for quick test (20 or so) then I run Prime95 blend test for finally because I have passed 100+ passes of LinX to only fail prime in 5 hours of testings. So I use prime 12-24 hours to decide if stable or not.

 

[BababooeyHTJ]

The one thing I question will linpack/linX is whether thermal induced failures there are accurately representative of system instability.

This is my take on things-
There really are 2 primary failure modes of an oc that lead to instability: the capability of the chip (and mb to some extent), and the thermal load. While related, I think you can get failures from either side independently. The capability aspect is whether the chip can be stable under a given multiplier/bclk/voltage etc, whereas thermal failure might have a chip that is otherwise capable but simply the temperature alone leads to a crash.

While I use linX plenty and don't doubt it's ability to test a CPU oc for it's raw capability, I have always wondered if there were thermally induced instabilities that are not realistic. I have not found or heard of a real application, even at continuous and extended load,that generates anywhere near the thermal loading that linX can. My concern is that an otherwise stable oc may be crashed in linX solely due to excessive heat not representative of anything real, and potentially past the point of saying that it is just more quickly revealing minor problems in the oc.

I don't go running stress tests on hot sunny days without the a/c on. I do game under those conditions at time. So yes I consider those temps that I see in Linx now temps that I may actually see in the summer time.

 

[stren]

I usually use linx to dial in an overclock because it's much faster to find errors. Some people claim IBT is the most reliable/extreme these days though I don't use it. Once i'm done with that I'll prime for a while say a 3-4 hours, and then bump vcore up a notch and start folding SMP and then bigadv. I know it's bad to fold before you know you're 100% stable, but I've been lazy in the past and the bump in vcore usually is enough to cause no problems. In future I'll probably run stresscpu, it's based on the folding algorithms so as far as I'm concerned it's the most useful:

http://folding.stanford.edu/English/DownloadUtils

I'm not usually concerned about heat because I'm on water with plenty of rads and I'm not pushing crazy speeds. I think a lot depends on what you're using it for, gaming doesn't need to be as stable as work, and work may or may not need to be as stable as say folding. My main problem with prime is just how long it takes, I want some margin of stability so an unrealistic load is good, but I don't want to worry about degrading my cpu running some crazy load for a week while I dial in exact settings (more of a problem when on air and running hot).