using Memtest86+

  • Thread starter Thread starter Synapse Syndrome
  • Start date Start date
Yes it can... by elimination... study its settings far more closely
Remember that today's CPUs have very big internal caches. Some of the
Prime95 documentation dates from a time when CPU caches were small.
You'll figure it out.


If you were thinking that the Large FFTs test would be an
isolation, it is not. I've tested a few CPU that will
(barely) fail that test while passing the Small & Blend(ed)
tests, it was definitely not the memory - merely reducing
CPU multiplier or raising CPU vcore resolved the problem
(CPU was overclocked, BTW).

I suppose one could define some other size, but it still
doesn't necessarily isolate the memory. Remember that some
CPU now have on-die memory controllers so some *memory*
related errors are still actually CPU errors.
 
kony said:
If you were thinking that the Large FFTs test would be an
isolation, it is not. I've tested a few CPU that will
(barely) fail that test while passing the Small & Blend(ed)
tests, it was definitely not the memory - merely reducing
CPU multiplier or raising CPU vcore resolved the problem
(CPU was overclocked, BTW).

To clarify, neither memtest86 or any Prime95 test can tell you directly
whether a problem is caused by memory timings, northbridge problems or
FSB issues at either end. One can assume a memory cell fault if
memtest86 picks up the same address repeatedly.

Prime95 large FFT will pick up many common CPU execution issues as well
as memory-path problems, so you have to use the small FFT test to
exclude these. Memtest86 rarely picks up CPU-local issues, although it's
not unknown. All those memory addressing ops still go through the CPU
pipeline.
 
|
|
| >Prime95 cannot discriminate between CPU and chipset or
| >memory errors, and far more often generates errors from an
| >instable CPU than memory.
| >
|
| Yes it can... by elimination... study its settings far more closely
| Remember that today's CPUs have very big internal caches. Some of
the
| Prime95 documentation dates from a time when CPU caches were small.
| You'll figure it out.


Using Prime95 to ascertain whether errors are CPU or memory subsystem
related is like using a voltmeter to troubleshoot a radio frequency
circuit. You can measure some DC power supply voltages, but you can't
determine what part of the high frequency circuit is having problems.

Since the OS will use a portion of memory, and the OS HD cache will
use a chunk of system memory, it is not reasonable to use Prime95
(which must run under an OS) as a complete memory test other than to
proceed with the assumption that an error from Prime95 can mean either
CPU instability OR a memory subsystem problem/error. Similarly, the
use of 3dmark as a system stability test cannot identify the problem
area as you will now have to consider that the graphics subsystem may
be the root of the problem (GPU overheating or GPU/video-memory access
errors), in addition to the potential for an overheated CPU or memory
subsystem problem. If memtest86 kicks out errors, and one still
suspects the CPU might be overheating, one can attempt to lower the
CPU multiplier without lowering memory access timing speeds and
retest. Alternatively, one can attempt to better cool the CPU by
opening the case and placing a window fan by the case to blow air into
the case as an over-the-top form of additional system cooling. If
lowering the CPU multiplier is not possible, then lowering FSB
frequency or system frequency would be the next option in attempting
to find a stable system speed to pass memtest86. Finally, relaxing
memory timings is another option to use with memtest86 to determine
memory subsystem stability.
 
Back
Top