Simultaneous torture testing with different programs

M

MechGeek

Limp Gawd
Joined
Jun 16, 2004
Messages
230
Ok, this is really weird.

I had the idea to run two *different* torture test programs at the same time, instead of many threads from the same one. It's counterintuitive, I know... it slows down the torture tests, but it also makes two hungry processes (each coded in their own style) fight aggressively for resources and clobber said resources in their own way.

Well... the machine in my sig (i7 @ 3.8, Prime95 stable + IntelBurnTest/Linpack stable) was stable for at least 12 hours of continuous torture testing. When I ran them simultaneously, both torture test programs started returning calculation errors in less than 10 minutes.

A minor voltage adjustment wasn't enough. I raised the voltage from 1.275 to 1.400 and STILL wasn't stable+accurate at 3.8GHz. Or 3.6. I had to go all the way down to 3.48GHz, at 1.4V, to get Linpack and Prime95 to run flawlessly side-by-side. It was single-torture-test stable @ 3.48GHz & stock 1.2V.

Anyone else who's run simultaneous torture tests--Any thoughts you'd like to share?
Anyone who hasn't run simultaneous torture tests (with checks for calculation accuracy) .... don't do it, you will probably get your heart broken. ;)

*****EDIT*****
The reason it wasn't stable at 3.48 @ 1.4V was because my CMOS was corrupted......along with random files on my hard drive. After resetting CMOS to default values, I found a stable set of clocks & voltages using simultaneous torture testing, then reformatted.

All the random weirdness is gone, and it's stable at 3.6GHz @ 1.38V for 13 hours of IBT+Prime95 side-by-side. (PROOF)

If you have an overclocked and/or undervolted multicore machine that you do ANY critical work on, we advise you to read the rest of this thread. If all you use your OC'd machine for is games, and your system is stable enough, and your important data is stored elsewhere, then disregard.


 
Never thought about doing it. I'll have to give it a try when I get home.
 
I've done it but i still see no point in doing it. These stress tests run the cpu past normal usage and for several hours at that!

its a situation that will rarely/never happen.
 
That's the thing, I can get calculation errors in a matter of minutes. Data corruption in such a scenario is plausible if, say, I was rendering a video and playing Crysis Warhead at the same time.
 
I found that my machine was Prime95 stable, but Prime95 + 20 minutes of TF2 gaming would blue screen. Turned out to be qpi/vtt needed to raised from 1.2 to 1.37v to be stable. Sounds like you might need to adjust that instead of cpu voltage/speed.

I've also run P95 + Core Damage, SuperPi 32M, wPrime 1024M. Will try IBT and LinPack, since you mentioned it worked to find instability.
 
IBT is basically a front-end for Linpack so you don't need to get them separately.

IBT and Prime95 work very well together on the i7's because IBT only uses 50% of the total CPU.
Then, running 4 threads of Prime95 will fill the other 50%. And they both check for accurate calculations, which is important IMO.

Start Prime95 first then IBT. Pick how much RAM you want to use for Prime95 (1.6GB seems to be the limit regardless of what's in the box). Then load IBT and select "Maximum stress test" to automatically allocate the rest of the memory you have. Or else you can select Custom and it'll ask you how many MB you want to use so you can have some left over for other tasks.

Amazingly, browsing while 2 torture tests are running isn't that bad on the i7 in Win7. :)


Here are links for anyone wanting to try this:
IBT/Linpack: http://downloads.guru3d.com/IntelBurnTest-v1.6-download-2047.html (32/64 bit)
Prime95: 32 bit - 64 bit

Both programs run from wherever you extract them (i.e., no installer).
 
Yeah, TF2 runs at 50-120 fps while running 8 threads of Prime95! I was wondering why there was no 64-bit Prime95, guess I overlooked it.
 
:eek: Nice! I always killed off 2 Prime95 threads before gaming....didn't think of trying without. That's another good torture test. And fun!
 
Prime 95 is set up to relinquish cycles to other programs if needed (it has a low priority by default). IBT on the other hand, does not. With IBT running I'm not sure how many cycles are getting thrown at Prime95. I know even browsing is a pain with IBT running.
 
I ran Prime95 four threads (1.6GB ram), then IBT set at low priority (2.6GB ram) with ten loops. Then fired up CS:S with some bots, and within 5 minutes it took out my "on the bleeding edge" OC settings (bare minimum stable) but not my "step back from the edge" (for about an hour). Definitely the best stress test so far. Looks like I've got a new minimum, and I need to step back a couple notches again for my safety margin. I'm getting there, tough stuff finding a stable aggressive overclock.

I wonder how many of those i7 3.8 to 4.2 GHz overclocks are truly stable...
 
If you're putting 5 times the amount of stress on your system than you're ever going to put on it in real usage - what is that proving exactly? That it is 5 times as stable as it needs to be?
 
if a system is not stable, it is not stable, that is how i see it, sure you may not put that much stress on it, all the time, but what about that one time you do? what if it is something important and BAM, reboot, you lose it all!
 
Forceman said:
If you're putting 5 times the amount of stress on your system than you're ever going to put on it in real usage - what is that proving exactly? That it is 5 times as stable as it needs to be?
Click to expand...

That's exactly right. If it isn't stable under the most demanding usage, then it doesn't make the cut. You never know when some small snippet of code will push the chip over the edge for an instant causing silent data corruption. That's why I am testing for a stable setup, and then push the voltage up a bit and the clocks down a bit after that. Stability is king!

It's just that this i7 is being 10x harder to qualify as stable than my old single core system. We need a program that burns 7 threads like Core Damage, and then runs one self-checking thread -- and then does that for each thread unit in turn of course.

:eek:
 
CPUs are heavily tested for accuracy and stability at their stock speed by the manufacturer. Why should we do any different with our OC'd speeds?

A CPU should never, EVER return an incorrect calculation if it is to be considered stable, no matter what the circumstances. No ifs, ands, or buts. When a stock CPU has a flaw that makes it return an incorrect calculation in a certain combination of extremely unlikely conditions, it's an "errata" and a it's very serious issue. Remember the Pentium FDIV fiasco? Or, more recently, the Phenom TLB bug? Recalls happen, lawsuits happen, it's a VERY big deal.

It's so serious because the OS is constantly writing to critical files (registry, journaling, defragging, etc)... and if the chip gets pushed over the edge for an instant while ANY disk I/O is occurring, it is very easy to corrupt files. What if a CPU-intensive program starts swapping to the pagefile? What if it miscalculates which disk sector to write? I've seen it happen. A friend's OC'd machine gave disk errors after he rebooted. I looked at the boot sector and there was a chunk of Word document where the bootstrap and partition table should've been. :eek:

And that's why we want to be sure an overclock is 100% stable no matter what the circumstances, before we do any serious work with it. But to do that, we have to load it six ways from sunday to even hope to recreate what would be going on in a processor during a "bad instant".
 
So why hasn't this method of testing been made the standard?

I'm sure plenty of people have thought about doing it. Even from the beginning.
 
Wow, this P95 + 64-bit IBT + gaming method really raised the floor on my minimum CPU voltage. 3.7 GHz went from a previous 1.21875v to 1.25625v now. Readjusted the stable 3.66 settings to 1.28750v, dang.

Will try 64-bit P95 later, their web page was down when I tried earlier.
 
At some point, someone needs to say stop the madness. What's next, testing the PC in the oven, because damn, someday this global warming shit is going to get real?

Test as much as you fell necessary, it is after all your machine, but this really reminds me of the scene in Something about Mary where the guy is defending his 6 minutes abs thing - no way man, no one will ever come out with 5 minute abs, what are you insane. Fill in multiple instances of Prime 95 and you get my drift.

How many simultaneous torture tests are enough? If it's stable with Prime95 and IBT, then what about if I plug OCCT on top of that, and then loop 3dMark at the same time. Hell, I'd better run LinPack for GPUs on there too - don't want that video card slacking off.

Even at stock speeds, sometimes systems have glitches, a cosmic ray blasts through the RAM at just the wrong time or a stray electron electro-migrates through the wrong part of the CPU, but I'm not running 3 Mile Island out of my house, or controlling the Space Shuttle - if my x264 encode of Dark Knight has a frame drop, who cares? My guess is your odds of damaging the CPU by overstrssing it is higher than the liklihood of my ever having an unrecoverable error in an overclock that fails the "7 instances of Prime 95 while running IBT and Core Damage with the case in a paint mixer" test.

And cue the "you don't understand the purpose of stability testing" replies in 3...2...1...
 
If you don't want to do it, then why are you trolling this thread.
 
Forceman said:
And cue the "you don't understand the purpose of stability testing" replies in 3...2...1...
Click to expand...


... 0


You just don't understand the purpose of stability testing!!! :)



But seriously-- if your computer is such a bad ass, do you test it with rainbows and skittles, or iron, a pair of pliers and a blow torch??
 
You might as well throw the GPU into the mix for full PSU stability testing.

The new OCCT 3.0 is out, which will run

"A Power supply test, made of a 3d test and a CPU Test. The power consumption of your computer will reach new highs. Measures shows a power consumption that is 40% higher than Crysis or 3DMark."

http://www.ocbase.com/perestroika_en/index.php?News
 
Running simultaneous IBT + Prime95 took my "stable" OC from 3.8 @ 1.275V to 3.6 @ 1.375V.

What needs to be done is to subject a well-built machine @ stock settings to this same torture test methodology. Would it also fail?
 
You have to keep in mind that most of these programs are not meant to be run simultaneously and that can cause conflicts. In the case of something like this, you can't guarantee that a hardware or software failure occurred.

That said, I don't trust stability tests only. That's one of the reasons I do my normal everyday tasks along with the stability tests. That way the video card, RAM, disks and other things get tossed into the mix in stressing the CPU. Normally this won't actually stress the CPU much more than the stability test is already doing, but it usually brings out an instability earlier than just running the stress test only. For me it's a time saver more than anything.

 
honolululu said:
You might as well throw the GPU into the mix for full PSU stability testing.

The new OCCT 3.0 is out, which will run

"A Power supply test, made of a 3d test and a CPU Test. The power consumption of your computer will reach new highs. Measures shows a power consumption that is 40% higher than Crysis or 3DMark."

http://www.ocbase.com/perestroika_en/index.php?News
Click to expand...

Will have to try that out. I've been using TF2, CS:S, and FC2 manually to stress the GPU. Also, I read about something called "FurMark" that is pretty punishing to GPUs on another forum.

edit: holy cow, FurMark makes the 55nm 260 fan speed up to almost 100%! :eek: I've never had the fan change from 40% before.

OCCT power supply test is much much better at loading the PSU than IBT + FurMark. That program is scary.

Measured 565 watts (!!) from the wall for loaded oc i7 + 260 "stock evga ssc". If you take into account the 83% efficiency of the Corsair HX620 PSU, that's 469 and 115 watts inside, respectively. Man, those numbers are way way higher than my old rig! Hrmph, I overbuilt...

Anyways, seems like my system is surviving everything I'm throwing at it now at the same time. This stuff was a major help!

:cool:
 
sigh... I had a suspicion I was a victim of silent file corruption before I started this thread, and it's true.

Before I tried the simultaneous torture tests, I was running a Prime95 test at 4GHz. It was working, but Windows suddenly got the idea that doing a background defrag in the middle of the test was a good idea. (I guess... the hard drive light was flashing for about 5 minutes)

The next time I loaded Trillian and Notepad++ (they were running during that test) both programs complained about corrupted XML configuration files.

"But it was Prime95 stable" I thought, which is why I grabbed IBT. It passed as well. (although further testing indicated that IBT will find instability quicker and more reliably than Prime95...on i7 chips at least)
I ran IBT and Prime95 together and they both started returning calculation errors. And yes, as soon as I closed Prime95, IBT started returning correct residuals.

Anyway, I started noticing a lot of weird problems that I can trace back to that one fateful overclock.

For example, the Snipping Tool would leave behind an empty window (shown in taskbar) after each use. Windows Backup would create a system image, but then forget it was there and refuse to give me access to it. Sometimes the System Info window (Win+Pause) would just be a blank screen.

So...yeah, running IBT and Prime95 side by side exposed the instability of my overclock, but the damage was already done.

Once I was certain my OC was stable, I reformatted and reinstalled everything, as I couldn't remember if the last image backup I had was before or after that one OC attempt.

I don't mean to sound alarmist.... and I feel stupid saying "You should always back up before you test OCs" or "don't test OCs on a machine you're not ready to reformat" .... but as I said before, I worked on a PC for a friend whose HD got corrupted in a bad way from OCing and saw the evidence first-hand with a hex editor. And now mine got a few bits flipped in random places that I happened to notice. So be careful out there... ;)

Still, I can understand the arguments against simultaneous torture testing and possible conflicts... I think the only way to resolve it, for me, is to run the same test on some stock-clocked machines. Only problem is, most stock clocked machines may have trouble with their stock coolers... :)
 
Yeah, I have plans to re-install when I'm done testing. Though nothing appears corrupted after a few dozen freezes and blue screens... I tend to tap the reset button at the first signs of weirdness... but one can't be sure...
 
instead of IBT, try LINX - another front for linpack but much better, and very suitable for i7s, loads up all 8 threads, tests cpu and memory.
 
Well I thought prime95 was good enough for my i7. Ran the x64 version and it had 8 threads going, and all my threads showed 100% usage. 3.8 @ 1.3V was stable with no errors for 24 hours. Will have to try running a few others when I get home.

Not sure if I agree with it yet, esp since bad driver/software conflict corruption is more likely than my CPU (which only showed calc errors after running multiple stress tests).

Guess I will find out later.
 
i do this for the cpu and gpu but not more than one program for the cpu at one time...that seems silly to me.

orthos+furmark
 
Forceman said:
At some point, someone needs to say stop the madness. What's next, testing the PC in the oven, because damn, someday this global warming shit is going to get real?

Test as much as you fell necessary, it is after all your machine, but this really reminds me of the scene in Something about Mary where the guy is defending his 6 minutes abs thing - no way man, no one will ever come out with 5 minute abs, what are you insane. Fill in multiple instances of Prime 95 and you get my drift.

How many simultaneous torture tests are enough? If it's stable with Prime95 and IBT, then what about if I plug OCCT on top of that, and then loop 3dMark at the same time. Hell, I'd better run LinPack for GPUs on there too - don't want that video card slacking off.

Even at stock speeds, sometimes systems have glitches, a cosmic ray blasts through the RAM at just the wrong time or a stray electron electro-migrates through the wrong part of the CPU, but I'm not running 3 Mile Island out of my house, or controlling the Space Shuttle - if my x264 encode of Dark Knight has a frame drop, who cares? My guess is your odds of damaging the CPU by overstrssing it is higher than the liklihood of my ever having an unrecoverable error in an overclock that fails the "7 instances of Prime 95 while running IBT and Core Damage with the case in a paint mixer" test.

And cue the "you don't understand the purpose of stability testing" replies in 3...2...1...
Click to expand...

QFT - everyone listen to this guy.
 
mikecoscia said:
Shouldn't any CPU start to give errors eventually if you keep piling on different tests/apps, no matter the clock? Isn't there just a point were it can't handle it anymore?
Click to expand...

I'd say yes and no. As for pushing the CPU to do too much, you probably aren't going to make CPU errors happen that way. The CPU can only process so much and the rest sits on the backburner until it can be processed. The most you're going to get with this is a slowdown between results on the different tests and this is a best case scenario.

The reason I say yes with multiple stress tests running is because you're not going to have a best case scenario. Most stress tests are aiming to take up 100% of the resources they are designed to test. Because of that, they aren't made with other programs running simultaneously in mind. Running two or three of these at the same time and getting errors doesn't mean the problem is with the hardware, but could easily be a conflict between the programs you are running. They all want high priority and full system resources which is not something you run into very often with regular software. Even if you run into what looks like hardware instability, it's difficult to determine whether the instability came from the hardware or because of a conflict between the different programs.

When I'm doing video encoding I don't normally run any other software which puts heavy loads and demands on my hardware. This is done because I prefer to have the encodes done as soon as possible and I don't want different software conflicting and fighting over resources. This can introduce problems with the encodes which is something I definitely do not want. However, I still do my regular browsing, watching movies, email, etc. Those activities do not put heavy loads on the CPU, RAM or anything else which is needed for encoding.

I don't personally suggest running multiple stress testing programs at the same time. If you want to run one and find the system is stable and then shut it down and run another one for stability testing, that's just fine. You're only testing the hardware and keeping as many variables out of the mix as possible. This is one of the main reasons why memtest is used for RAM problems. It runs on its own with a tiny OS made to run memtest and memtest only. You don't have anything else trying to use RAM which allows you to test just about every last byte of RAM and no other software in the background conflicting with the test.
 
SmokeRngs said:
I'd say yes and no. As for pushing the CPU to do too much, you probably aren't going to make CPU errors happen that way. The CPU can only process so much and the rest sits on the backburner until it can be processed. The most you're going to get with this is a slowdown between results on the different tests and this is a best case scenario.

The reason I say yes with multiple stress tests running is because you're not going to have a best case scenario. Most stress tests are aiming to take up 100% of the resources they are designed to test. Because of that, they aren't made with other programs running simultaneously in mind. Running two or three of these at the same time and getting errors doesn't mean the problem is with the hardware, but could easily be a conflict between the programs you are running. They all want high priority and full system resources which is not something you run into very often with regular software. Even if you run into what looks like hardware instability, it's difficult to determine whether the instability came from the hardware or because of a conflict between the different programs.

When I'm doing video encoding I don't normally run any other software which puts heavy loads and demands on my hardware. This is done because I prefer to have the encodes done as soon as possible and I don't want different software conflicting and fighting over resources. This can introduce problems with the encodes which is something I definitely do not want. However, I still do my regular browsing, watching movies, email, etc. Those activities do not put heavy loads on the CPU, RAM or anything else which is needed for encoding.

I don't personally suggest running multiple stress testing programs at the same time. If you want to run one and find the system is stable and then shut it down and run another one for stability testing, that's just fine. You're only testing the hardware and keeping as many variables out of the mix as possible. This is one of the main reasons why memtest is used for RAM problems. It runs on its own with a tiny OS made to run memtest and memtest only. You don't have anything else trying to use RAM which allows you to test just about every last byte of RAM and no other software in the background conflicting with the test.
Click to expand...

Thanks for the reply and that was pretty much what I was thinking running multiple tests, as far as how the hell do you know what caused the BSOD, hardware or software.
 
mikecoscia said:
Shouldn't any CPU start to give errors eventually if you keep piling on different tests/apps, no matter the clock? Isn't there just a point were it can't handle it anymore?
Click to expand...

Absolutely not, a proper stable system will run 24 hours a day under max load.
I am a bit surprised how solid stability gets the cold shoulder...
 
Just downloaded Intel Burn Test v1.9. Never used it before and wanted to give it a try compared to Prime95 and maybe run both at the same time for the hell of it. However IBT is not stressing all threads at the same time, it jumps around alot. It does use all 12GB of my ram though. Did I miss a setting somewhere?
 
Here's some proof that a proper, stable OC'd system will run multiple torture tests without failing. (click for fullsize image)


Prime95 + IBT running side by side for 13 hours @ 3.6GHz.
 
Forceman said:
At some point, someone needs to say stop the madness. What's next, testing the PC in the oven, because damn, someday this global warming shit is going to get real?

Test as much as you fell necessary, it is after all your machine, but this really reminds me of the scene in Something about Mary where the guy is defending his 6 minutes abs thing - no way man, no one will ever come out with 5 minute abs, what are you insane. Fill in multiple instances of Prime 95 and you get my drift.

How many simultaneous torture tests are enough? If it's stable with Prime95 and IBT, then what about if I plug OCCT on top of that, and then loop 3dMark at the same time. Hell, I'd better run LinPack for GPUs on there too - don't want that video card slacking off.

Even at stock speeds, sometimes systems have glitches, a cosmic ray blasts through the RAM at just the wrong time or a stray electron electro-migrates through the wrong part of the CPU, but I'm not running 3 Mile Island out of my house, or controlling the Space Shuttle - if my x264 encode of Dark Knight has a frame drop, who cares? My guess is your odds of damaging the CPU by overstrssing it is higher than the liklihood of my ever having an unrecoverable error in an overclock that fails the "7 instances of Prime 95 while running IBT and Core Damage with the case in a paint mixer" test.

And cue the "you don't understand the purpose of stability testing" replies in 3...2...1...
Click to expand...

Yes, but even here at [H] a lot of people still don't bother to truly test out the stability of their overclocks. Last time a thread like this started up I found it surprising that several people replied back stating that they don't bother doing the usual 8-12hrs Prime95 to test overclock stability and if the pc handles games and other simple tasks fine then they consider the pc stable. I wonder if these people are the same ones who later up start threads about how their video card drivers suck/ cannot install properly and how other OS/software related stuff goes haywire in their system.

Well in my case I only have a Q6600 so I can't run IBT/Prime95 at the same time, but I've dabled in extreme stability. My Q6600 @ 3.897 passed 103 IBT runs stable and later to insure stability I ran two instances of Prime95 for a period of 24 hours during which I also fired up Furmark several times, one time for a period of 3 hours which my PC handled no problem.
 
You must log in or register to reply here.
Back
Top