Overclocking CPU/GPU/Memory Stability Testing Guidelines

[Tsumi]

LinX/IBT only performs the error checking for stability purposes at the end of every cycle.

If you don't iterate through X-cycles then you have not stress tested your system to see if it is capable of repeatedly calculating the same set of computations X-number of times.

Precisely because the time involved per cycle is memory dependent (depends on how much ram you have installed and are testing), there is every reason to carry out the stress testing on a cycle-basis versus a time-basis.

The very same reasoning why you carry out ram stability testing on a cycle-basis (times through the loop test) which is also called "% coverage".

I can see the logic in that. But here's my argument:

If your RAM has already been proven stable with HCI memtest for example, then any errors made would be completely CPU dependent. So, if there were any errors made during the calculation, it would accumulate over time and reported at the end, not during a specific run. So arguably, you should run HCI memtest first for X cycles, so as to eliminate RAM from any overclocking issues.

 

[Idontcare]

I can see the logic in that. But here's my argument:

If your RAM has already been proven stable with HCI memtest for example, then any errors made would be completely CPU dependent. So, if there were any errors made during the calculation, it would accumulate over time and reported at the end, not during a specific run. So arguably, you should run HCI memtest first for X cycles, so as to eliminate RAM from any overclocking issues.

I think you misunderstood what I was saying. I was saying there is a reason why you stress test your memory with the notion of cycles or %-coverage in mind.

Extend that same reasoning to stress testing your CPU when using iterative software like LinX. The software itself is designed to work in passes or cycles, not in absolute time.

You can use it in absolute time mode but doing so fails to capture the very reason why the software itself wasn't designed to operate the error checking that way in the first place.

I wouldn't run memtest+ and just report back "well it ran fine for 10hrs, so I'm good, right?" because 10hrs of memtest+ on 2GB of DDR3-2133 ram is providing for a very different testing regiment as 10hrs on 24GB of DDR-1333 ram. What I should care about, and what you would care to hear about, was whether or not my ram - be it 2GB or 24GB - passed 10 cycles (1000% coverage) of the entire memory test regiment.

If I was testing 24GB of ram then the total time involved will be much larger than that required for 2GB.

Same with using LinX. Passing 1hr on LinX means what? Nothing since it is designed to only error-check for instability at the end of every cycle. Tell me it passed 20 such error-check iterations then that will mean something to me regardless the clockspeed or core count of your CPU.

 

[AdamK47]

LinX will check the results for the entire cycle. Time is still a major factor. You could have 1 error within 20 cycles at 3GB or 1 error with 4 cycles at 12GB. It will still detect that error.

 

[Tsumi]

My logic was this:

Memcheck has to be done in cycles, because only one cycle can do 100% coverage of the memory.

The CPU does not work in one big cycle. It runs lots of calculations over and over, in very small, short intervals. If it makes an error in one calculation, LinX will not detect and report it right away, but at the end of the cycle. But the errors occur on a time basis, not a cycle basis, due to the nature of CPU calculations and how it is tested. That is how I see it at least.

 

[thewhat]

Testing with more RAM can bring up higher temperatures. But if you have good cooling that shouldn't be an issue.
So I'm wondering if testing LinX with more RAM has some (non heat related) error seeking advantage over testing it with fewer RAM for the same duration (but with more cycles).

 

[Idontcare]

Testing with more RAM can bring up higher temperatures. But if you have good cooling that shouldn't be an issue.
So I'm wondering if testing LinX with more RAM has some (non heat related) error seeking advantage over testing it with fewer RAM for the same duration (but with more cycles).

Absolutely it is better to test with "All" available ram. The 3rd bullet in the OP under the LinX entry is "Set memory to All".

Testing with anything less than all your system's available memory is really something that should only be done when you are attempting to normalize some of your settings if you are trying to generate GFlops numbers that are comparable to another system, since the ram size changes the GFlops.

But if the goal is to test the stability of your system then you need set the memory usage to all of the available ram since your system is going to be making use of all that available ram in the future as you use the rig.

 

[Tetedeiench3]

Testing with more RAM can bring up higher temperatures. But if you have good cooling that shouldn't be an issue.
So I'm wondering if testing LinX with more RAM has some (non heat related) error seeking advantage over testing it with fewer RAM for the same duration (but with more cycles).

Yes, there are quite a few things to know about Linpack (wether you use the LinX version or any other packaged version) :
* The more memory you use, the longer each cycle will take (more memory = more dfata to compute). The relation is not linear though.
* Error checking is only done after TWO cycles are done. Doing less than two cycles = no error checking
* Linpack brings your CPU to higher temperature than anything else yet, but error detection seems to be less effective than regular Prime95/CPU:OCCT (that's personal testing on aquite a few computers, mind you, this will probably not be always the case, as error detection is, by definition, based on random and chance).

It is hard to give you a rule like "it is better to do 3 hours with 1GB than 1hour with 3GB".

Don't forget also than using more memory will put a different load on your chipset and every component that link your CPU to the memory (caches, and such).

personally, i would say that using 24GB of memory for stability testing is a waste of time. i'd rather stick to 6GB in that case and get more cycles done, than using alll that memory, just to get the basics of error checking done much faster (i.e. if a cycle lasts 50min, you will know you had an error after 1h40min, whereas if you have a cycle of 20min, you would know after 40min).

Going too low is going to hinder the error detection capacity of the linpack test.

Again, this is just y personal experience, others may have different test results.

 

[Tetedeiench3]

If you click full screen in the GPU 3D, crossfire/SLI will work.

Indeed. Use crossfire, and tick that box, and you're good to go. i'm planning for the future to get a boox to select the adapter you want to use during testing. i'm afraid it won't be for 4.1.0, but it should be soon.

GPu:3D DX10 is going forward, still needs lots of optimization (error detection rate is not that great yet), but it already puts more load than the old GPU:3D DX9 on the gpu (try it out if you want to http://www.ocbase.com/download.php?fileext=beta )

 

[paperfist]

Do you guys know of another download site for Prime95? The provided one keeps timing out on me

n/m found it on a overclocking site.

 

[Idontcare]

Do you guys know of another download site for Prime95? The provided one keeps timing out on me

n/m found it on a overclocking site.

Hmmm, that's of that it was timing out. Must have been a temporary glitch, its working for me now.

 

[paperfist]

Hmmm, that's of that it was timing out. Must have been a temporary glitch, its working for me now.

Strange I tried to get it again today from that link and the d/l times out. I'm able to get it from extremeoverclocking.com so it's no big deal.

 

[Grooveriding]

Thanks for this post/sticky.

I have a question, when I run linx it does not stress my CPU to 100% load at all times, it does spike up there at times, but generally shows at around 60-70% load per core/thread. I am setting threads to 6 and memory to all when I run it in linx. It also doesn't raise temperatures all that high, except when CPU usage does spike to 100%. Actually what I am seeing is different cores/threads jump to 100% load at times, while the rest hover in the 6X% area.

I'm comparing this to small FFTs in prime which is constantly pegged at 100% load and as high as I usually see temp wise on my CPU. I'm using coretemp to monitor load and temperatures.

Is this normal behaviour ?

edit: so I am assuming I should of shut off HT in the bios before running it ^^. That is why running with HT on and 6 threads had be at 50% usage. I enabled 12 threads and it is at 100% usage across all 6c/12t. durr

 

[Idontcare]

Thanks for this post/sticky.

I have a question, when I run linx it does not stress my CPU to 100% load at all times, it does spike up there at times, but generally shows at around 60-70% load per core/thread. I am setting threads to 6 and memory to all when I run it in linx. It also doesn't raise temperatures all that high, except when CPU usage does spike to 100%. Actually what I am seeing is different cores/threads jump to 100% load at times, while the rest hover in the 6X% area.

I'm comparing this to small FFTs in prime which is constantly pegged at 100% load and as high as I usually see temp wise on my CPU. I'm using coretemp to monitor load and temperatures.

Is this normal behaviour ?

edit: so I am assuming I should of shut off HT in the bios before running it ^^. That is why running with HT on and 6 threads had be at 50% usage. I enabled 12 threads and it is at 100% usage across all 6c/12t. durr

Yeah I should make it more clear in the OP.

Hyperthreading slows down LinX, as does thread migration.

To get maximum heat generation from LinX you need to do one of two things - (1) turn off HT in your BIOS before running LinX, or (2) pop open task manager and set the affinity for the LinX exe to every other core.

Personally I leave HT enabled and do the core-affinity thing so there is open threads for the kernel to do its thing in the background.

 

[Quinstol]

I appreciate this info, it's useful stuff to an overclocking newbie like me. I have noticed some odd things however, and I was wondering if anybody might be able to comment on them.

When I used the copy of LinX linked to in the OP, it didn't seem to work on my system. It would never get done with a pass and RealTemp figures indicated the CPU was in an idle state. The copy I downloaded from techpowerup.com worked and completed passes, but the version that pushed my CPU hardest temp-wise was a version bundled with AVS that I found on a blog. Is there any reason for using the version linked in the OP would be preferred over these alternatives? [Edit: Actually, I could be wrong about it being the OP's copy that wasn't running for me -- I'll go back and try it after my current test is over.]

Also, I'm using 8 GB of DDR3-1600, which my motherboard's auto settings had running at 1333 MHz to start with. I left it at that when I first started overclocking/stress testing, then later pushed it up to 1600 MHz, but I found that with the latter settings, LinX doesn't seem to be running as hard/fast. Instead of ~120 Gflops I get around around 99, and the CPU was running cooler as well.

Any idea what's going on there? Thanks.

 

[sequoia464]

Any idea what's going on there? Thanks.

Same issues here, I'm using an AMD system though - that might be my problem.

AMD's overdrive utility shows very little CPU activity, same with Asus's AI suite.

EDIT: just found this - evidently it does have issues with some AMD processors - there is a newer version available - Link .. http://www.xtremesystems.org/forums/showthread.php?201670-LinX-A-simple-Linpack-interface/page33

 

[Idontcare]

Same issues here, I'm using an AMD system though - that might be my problem.

AMD's overdrive utility shows very little CPU activity, same with Asus's AI suite.

EDIT: just found this - evidently it does have issues with some AMD processors - there is a newer version available - Link .. http://www.xtremesystems.org/forums/showthread.php?201670-LinX-A-simple-Linpack-interface/page33

Thanks! I will update the link in the OP if someone can post the link to the latest AMD compatible LINX/IBT

 

[sequoia464]

Thanks! I will update the link in the OP if someone can post the link to the latest AMD compatible LINX/IBT

I tried the version that was linked to at ExtremeSystems that is AMD friendly - it appears to be the same version linked on the first page of this thread. This post has the info ..

http://www.xtremesystems.org/forums...ck-interface&p=5009230&viewfull=1#post5009230

It says the AMD files were compiled on July 20, 2011 - so no help for me with this 6100. The three AMD posters that this did work for were using Phenoms.

So, if I understand correctly, there is not anything more current for AMD than what is already linked to here, possibly an updated version for Intel users though??

 

[AdamK47]

why we do or need overclocking?? i think it is a big cause of over heating which is dangerous for your pc!!!

I shall correct my errant ways. Thanks for registering on these forums and setting me straight.

 

[kevindd992002]

Is HCI Design Memtest really the best in determining memory stability?

I just used it today with my laptop with 2670QM CPU and Kingston HyperX PnP 2x4GB 1600MHz RAM modules. I've used 8 instances of the program with about 750MB for each to test. I left it running for more than 12 hours and when I get back home from work, there was an error on one of the instances at around 2300% coverage. I thought 1000% is considered to be Gold standard already, why did I still get an error at more than than 2000% coverage? How do you guys interpret this?

Thanks.

 

[Idontcare]

Is HCI Design Memtest really the best in determining memory stability?

I just used it today with my laptop with 2670QM CPU and Kingston HyperX PnP 2x4GB 1600MHz RAM modules. I've used 8 instances of the program with about 750MB for each to test. I left it running for more than 12 hours and when I get back home from work, there was an error on one of the instances at around 2300% coverage. I thought 1000% is considered to be Gold standard already, why did I still get an error at more than than 2000% coverage? How do you guys interpret this?

Thanks.

Its not the best, its just one of the best.

It has been shown to detect errors that memtest86+ fails to detect. But you should use both as they employ test pattern that are not identical. Orthogonal testing methods is preferred.

We are always looking for ways to improve the guidelines, feedback such as yours is invaluable in this regard. Thank you for contributing it.

As for "gold standard" that does not "bullet proof", just means you should shoot for that at a minimum if you want to have reasonable confidence in your rig's long-term stability.

If we were to run with the nomenclature, I suppose beyond "gold standard" we should have a "platinum standard" and then something along the lines of the "rhodium standard".

 

[kevindd992002]

Its not the best, its just one of the best.

It has been shown to detect errors that memtest86+ fails to detect. But you should use both as they employ test pattern that are not identical. Orthogonal testing methods is preferred.

We are always looking for ways to improve the guidelines, feedback such as yours is invaluable in this regard. Thank you for contributing it.

As for "gold standard" that does not "bullet proof", just means you should shoot for that at a minimum if you want to have reasonable confidence in your rig's long-term stability.

If we were to run with the nomenclature, I suppose beyond "gold standard" we should have a "platinum standard" and then something along the lines of the "rhodium standard".

Right. But technically I could leave my computer running for weeks and if the RAM is good I shouldn't experience a single error in HCI Design Memtest, right?

 

[Idontcare]

Right. But technically I could leave my computer running for weeks and if the RAM is good I shouldn't experience a single error in HCI Design Memtest, right?

Your ram will still experience soft errors, so it would be incorrect to assume your computer could run HCI Memtest for weeks without detecting a single error.

Having "good" ram simply means the SER will be inline with expectation, but the SER will not be zero.

However if you are asking if your ram is suspicious because it generated an error in HCI Memtest after ~2000% coverage then my answer is "yes, that makes me think your ram is borderline unstable".

You may need to bump the Vdimm up by just one notch in the BIOS, or you may need to reduce the Dimm temperatures a few degrees by placing a case fan such that more airflow passes over your ram.

If your ram is truly "stable as can be" then I'd expect it to be able to pass say 10,000% coverage in HCI Memtest without error. Not many are interested in leaving their rig alone for the required amount of test time though.

 

[kevindd992002]

Your ram will still experience soft errors, so it would be incorrect to assume your computer could run HCI Memtest for weeks without detecting a single error.

Having "good" ram simply means the SER will be inline with expectation, but the SER will not be zero.

However if you are asking if your ram is suspicious because it generated an error in HCI Memtest after ~2000% coverage then my answer is "yes, that makes me think your ram is borderline unstable".

You may need to bump the Vdimm up by just one notch in the BIOS, or you may need to reduce the Dimm temperatures a few degrees by placing a case fan such that more airflow passes over your ram.

If your ram is truly "stable as can be" then I'd expect it to be able to pass say 10,000% coverage in HCI Memtest without error. Not many are interested in leaving their rig alone for the required amount of test time though.

Problem is that the system I'm referring to is my laptop which has limited BIOS options and no option in changing RAM voltage or timings

 

[Idontcare]

Problem is that the system I'm referring to is my laptop which has limited BIOS options and no option in changing RAM voltage or timings

In that case I'd re-run the memory stress test a few times and see how repeatable the failure is. If it repeats the try memtest86+ and see if it gives you an error as well.

You may have a bad stick of ram in your laptop.

 

[kevindd992002]

In that case I'd re-run the memory stress test a few times and see how repeatable the failure is. If it repeats the try memtest86+ and see if it gives you an error as well.

You may have a bad stick of ram in your laptop.

I tried doing that and yes I also see errors in Memtest86+ and even in Windows Memory Diagnostic tool. Weird thing is that I get it when using both sticks of RAM. When I try them one at a time, they are error-free. I already tried RMA'ing them and when I got the new kit, I still experience the same.