Memtest86+, ver, 1.65

  • Thread starter Thread starter Richard Dower
  • Start date Start date
David said:
larry moe 'n curly wrote:

That's an interesting test but you need to interpret it properly as well.

Finding a known error is fine. Not finding an error when there isn't one is
fine too. The key here is 'known' However, what about the typical use where
neither is 'known', which is why you're running the test, and it pops up an
error? Module is bad, right?

Not necessarily. As the article also points out "The results of these tests
also point out that memory problems are not necessarily related to physical
DRAM chip defects. There may be data bus, address bus, memory controller or
other memory subsystem component problems..." They left out that it could
also be a processor problem, especially if overclocked, a power supply
problem, a wiring problem, or just about anything that affects the ability
of the system to read/write properly into memory. Just about 'all of it'
has to work for the memory to work properly too so a problem almost
anywhere can create 'memory errors'.

With the systems I've used, 'all of it' always seemed worked fine (but
the only test equipment I have is a digital multimeter), except the
memory, and errors reported by memory diagnostics always disappeared
when I substituted another module, except in the case of some Kingston
PC2100 modules (the third one was fine). Also memory diagnostics like
MemTest86 and Gold Memory have never reported errors with modules
containing name brand chips, only those with no-name chips, and I doubt
that this is just a coincidence.
In other words, software memory testers tell you there is a problem with
your *system*, that appears to manifest as a memory error, not that the
module is automatically defective (although one hopes, and it is a hope,
that it's the likely candidate).

Except for connection, power, and capacitor problems, how likely are
memory errors not caused by the memory itself, assuming the right type
of memory is used and there's no overclocking?
 
larry said:
Shep© wrote:




Except for being slow, how do MemTest86, Gold Memory, and Ultra-X RST
"suck" at testing memory?

First let me say that I don't agree that they 'suck'. The problem is with
interpreting the results.
According to:

www.realworldtech.com/page.cfm?ArticleID=RWT120901222920

all three worked well, and RST detected 100% of the defects (provided
the computer could boot). Also none of the ten or so diagnostics they
evaluated gave any false positives.

That's an interesting test but you need to interpret it properly as well.

Finding a known error is fine. Not finding an error when there isn't one is
fine too. The key here is 'known' However, what about the typical use where
neither is 'known', which is why you're running the test, and it pops up an
error? Module is bad, right?

Not necessarily. As the article also points out "The results of these tests
also point out that memory problems are not necessarily related to physical
DRAM chip defects. There may be data bus, address bus, memory controller or
other memory subsystem component problems..." They left out that it could
also be a processor problem, especially if overclocked, a power supply
problem, a wiring problem, or just about anything that affects the ability
of the system to read/write properly into memory. Just about 'all of it'
has to work for the memory to work properly too so a problem almost
anywhere can create 'memory errors'.

In other words, software memory testers tell you there is a problem with
your *system*, that appears to manifest as a memory error, not that the
module is automatically defective (although one hopes, and it is a hope,
that it's the likely candidate).

So why do you believe that software-based memory diagnostics are bad?
Do you have any proof to back up your opinion?
Here's an example, Machine comes in.

user: My windows keeps throwing up BSOD's with memory addresses.

Me: when did it start and have you done anything lately.

user. a few days and No changes.

user: I ran memtest gold super duper memtester blah blah, says my memory is
bad, but comp store says every thing is ok.

me: how many errors and how often?

user: 5 in an hour and it seemed they were 'regular' like intervals

me: what's the scratches on the top of the case

user: my Florissant desk lamp

me: move the lamp away from your machine

next day
user: hey that worked and now that 'sound' from my speakers, when moving my
mouse, is gone.

memory is effected by lots of things.....try one of those magnetic backed
calendars on the case side


memtesters used in a suspect machine to check modules for accuracy and
ultimately whether or not they end up in the bin, is not 'normal
troubleshooting' procedure. NOT an opinion, fact, and when thought about
with the least amount of 'common sense' instead of blind allegiance, you
could see the reasons why.

fridge won't get cold....diag says the compressor is not circulating
coolant...replaced comp.....diag says...comp not circulating
coolant....replaced comp........diag says no coolant........how many times
before you fix the 'kinked' coolant line or check that compressor in another
machine or on the bench?

Most people don't bother checking more than once. They toss and cost.

what's the next argument with the same futility, the world is flat?
 
[snip] bloomin' heck...i was only giving folks the heads up on some updated
software, not a flame war.

:-(
 
Richard Dower said:
[snip] bloomin' heck...i was only giving folks the heads up on some updated
software, not a flame war.

:-(

Far from a flame war....and its fine to do that (heads up) however (no
matter what version) unless you use them in a different machine or test bed,
they are not useful. AFA ' mace ' I don't appreciate her assumptions and
then 'cuts and runs' to let someone else debate her side.
 
larry said:
With the systems I've used, 'all of it' always seemed worked fine (but
the only test equipment I have is a digital multimeter), except the
memory, and errors reported by memory diagnostics always disappeared
when I substituted another module, except in the case of some Kingston
PC2100 modules (the third one was fine). Also memory diagnostics like
MemTest86 and Gold Memory have never reported errors with modules
containing name brand chips, only those with no-name chips, and I doubt
that this is just a coincidence.

I love people who open sentences with "always" only to end them with
"except." And one person reporting "have never" reminds me of the 5 year
old who said he hadn't seen anything like it in his whooooooole life (all 5
years of it).

Now that we know what your experience has been, except for, we only have
what? Say a billion more to take a survey of?

Except for connection, power, and capacitor problems,

You do realize that those "except for(s)" alone already prove my point (it
only takes one).
how likely are
memory errors not caused by the memory itself, assuming the right type
of memory is used and there's no overclocking?

Oh, about <--- that much --->.
 
JAD said:
[snip] bloomin' heck...i was only giving folks the heads up on some
updated

software, not a flame war.

:-(


Far from a flame war....and its fine to do that (heads up) however (no
matter what version) unless you use them in a different machine or test bed,
they are not useful.

Of course they're useful. As either a confirmation there is, indeed, a
problem 'somewhere' or as a build time, before you load 'er up with
important data, diagnostic to see if there is a problem.
 
David Maynard said:
JAD said:
[snip] bloomin' heck...i was only giving folks the heads up on some
updated

software, not a flame war.

:-(


Far from a flame war....and its fine to do that (heads up) however (no
matter what version) unless you use them in a different machine or test bed,
they are not useful.

Of course they're useful. As either a confirmation there is, indeed, a
problem 'somewhere' or as a build time, before you load 'er up with
important data, diagnostic to see if there is a problem.
I guess its a defintion of 'useful'. To me anything thats going to take
hours and hours, to give me data that is questionable, is not useful to me.
 
David said:
That's an interesting test but you need to interpret it properly as well.

Finding a known error is fine. Not finding an error when there isn't one is
fine too. The key here is 'known' However, what about the typical use where
neither is 'known', which is why you're running the test, and it pops up an
error? Module is bad, right?

Not necessarily. As the article also points out "The results of these tests
also point out that memory problems are not necessarily related to physical
DRAM chip defects. There may be data bus, address bus, memory controller or
other memory subsystem component problems..." They left out that it could
also be a processor problem, especially if overclocked, a power supply
problem, a wiring problem, or just about anything that affects the ability
of the system to read/write properly into memory. Just about 'all of it'
has to work for the memory to work properly too so a problem almost
anywhere can create 'memory errors'.

I love people who open sentences with "always" only to end them with
"except." And one person reporting "have never" reminds me of the 5 year
old who said he hadn't seen anything like it in his whooooooole life (all 5
years of it).

I'm not five years old, and I reported my experience accurately.
Now that we know what your experience has been, except for, we only have
what? Say a billion more to take a survey of?

What is your point?
In other words, software memory testers tell you there is a problem with
your *system*, that appears to manifest as a memory error, not that the
module is automatically defective (although one hopes, and it is a hope,
that it's the likely candidate).
You do realize that those "except for(s)" alone already prove my point (it
only takes one).

My point is that memory diagnostics can and do reliably detect
defective memory.
Oh, about <--- that much --->.

Every time somebody gives a smart-ass answer like that, the person
doesn't know.
 
larry moe 'n curly said:
I'm not five years old, and I reported my experience accurately.


What is your point?



My point is that memory diagnostics can and do reliably detect
defective memory.


Every time somebody gives a smart-ass answer like that, the person
doesn't know.


Send your 'memtest' tested bad modules here.

You guys that are supporting this 'troubleshooting procedure' are
making yourselves look foolish. The mature thing to do is to admit that this
type of troubleshooting is NOT normal procedure, is not logical and lacks
the simplest form of common sense thinking.

Of the hundreds of machines that have been brought to me, MAYBE 5 were
actually memory related problems, where replacing the module, fixed the
problem. These were very obvious.(garbled bios text, removing one module
fixes it etc. still goes to the hardware tester however)
Most were software/drivers, overheating and PSU problems, along with the
occasional upgrade gone bad stuff.

I think the case as been made, and your refusal to admit that this way of
testing 'memory' (not the system) is far from productive, you are simply
arguing for the sake of it.
 
JAD said:
JAD wrote:

[snip] bloomin' heck...i was only giving folks the heads up on some

updated


software, not a flame war.

:-(




Far from a flame war....and its fine to do that (heads up) however (no
matter what version) unless you use them in a different machine or test
bed,
they are not useful.

Of course they're useful. As either a confirmation there is, indeed, a
problem 'somewhere' or as a build time, before you load 'er up with
important data, diagnostic to see if there is a problem.

I guess its a defintion of 'useful'.
Possibly.

To me anything thats going to take
hours and hours, to give me data that is questionable, is not useful to me.

It's the interpretation of the data that's the problem.

On the other side of the coin, pulling memory out and testing it on another
system doesn't test the 'suspect' *system*, just the memory module.

As for the time, it's not any different than a separate test machine. A
short test is not as robust as a longer one but the choice is yours. But if
you're trying to discern if the 'occasional lockup' is due to hardware or
software then a long test is likely necessary and, in the same vein as
testing things on a 'suspect' system, you can't isolate between hardware
and software by continuing to run it with suspect software.
 
larry said:
I'm not five years old, and I reported my experience accurately.

I didn't say you were 5 years old. What I said was you, as one person,
thinking your own personal experience somehow encompasses the entire range
of possibilities, or that ii is of any statistical significance in the vast
sea of things, is like the 5 year old who imagines his 5 years of life is a
'long time'.

Anecdotal stories are not translatable into the generic.

What is your point?

That your range of experience is but a spec in the billions.

My point is that memory diagnostics can and do reliably detect
defective memory.

That they "can" detect defective memory is true in the sense that defective
memory can cause errors, like other things can, and memory diagnostics will
report that something caused an incorrect result.

'Reliability' is an entirely different thing and depends on what you think
it's "reliably" doing. If you think it's "reliably" telling you a specific
piece of hardware in a suspect system is at fault then you're
misinterpreting the results and are mistaken. It's like having an insane
person diagnose their self. They may be right but it isn't something you'd
want to 'reliably' count on.
Every time somebody gives a smart-ass answer like that, the person
doesn't know.

Of course I "don't know" because your 'question' is an unknowable question
that's dependent on a gaggle of factors making it meaningless in the broad
sense you asked.

Which is exactly what my "smart-ass answer" depicts in it's equally
nebulous <--- that much ---> size.

That and the question being irrelevant. A 'non-zero' likelihood of the
problem being something else, which you've already established in your own
vast experience, is sufficient to show that failing a memory test while
running in a suspect system is not definitive 'proof' that the memory
module, vs something else in the suspect system, is bad.

And making a determination based on 'likelihood' is playing the odds. It's
certainly a common practice but it is not a 'test' of any kind.

Which gets back to your 'question' and the 'likelihood' being dependent on
a host of other factors that alter the odds I'd play. New system? old one?
ECS motherboard? generic memory or name brand? 10 buck power supply? system
temps? where's it located? and many more. Oh, and what did memtest say?
Because, while it isn't definitive, it does alter the odds game.
 
JAD wrote:

Send your 'memtest' tested bad modules here.

You guys that are supporting this 'troubleshooting procedure' are
making yourselves look foolish. The mature thing to do is to admit that this
type of troubleshooting is NOT normal procedure, is not logical and lacks
the simplest form of common sense thinking.

Of the hundreds of machines that have been brought to me, MAYBE 5 were
actually memory related problems, where replacing the module, fixed the
problem. These were very obvious.(garbled bios text, removing one module
fixes it etc. still goes to the hardware tester however)
Most were software/drivers, overheating and PSU problems, along with the
occasional upgrade gone bad stuff.

I think the case as been made, and your refusal to admit that this way of
testing 'memory' (not the system) is far from productive, you are simply
arguing for the sake of it.

I know it's frustrating but it's an interesting study in hidden
factors/bias and your comment "Of the hundreds of machines that have been
brought to me" sets the stage.

What I mean is, you look at a suspect system as a suspect system and judge
a 'test' tool as a test tool because that's your business. You get a never
before seen machine because it isn't working right and need to diagnose it
in the least amount of time and can't afford the luxury of 'how ever long
it takes'. So, 'broke machine' and run memtest tells you almost nothing
other than what you already know: it's broke.

But they're not coming from that perspective. Take the poster who wanted to
argue that each of my examples didn't apply. He'd checked the PSU with a
DVM and 'scope, he said. Fan's are running. Heatsink is clean. Temps are
good. Even the module contacts are clean, and so on and so on. In essence,
what they do is diagnose, by whatever means, that it's most likely bad
memory and, so, run a memory diagnostic which, surprise, 'often', or
usually, or whatever likelihood that fits, says there's bad memory.

No wonder they think it's great. It just confirmed what they'd already
pretty much concluded or, put another way, they've decided by other means
it's a memory problem and the 'memory tester' says the machine is still
broke so, yep, it's a memory problem... often... usually... "except for"
(the times their already concluded diagnosis wasn't quite right). Those
plus the normal odds that a 'problem' is likely a memory problem anyway
like, "I put in new memory and have a problem so I ran memtest and,
shazzam, it said I have a problem" ("except for" the times it was when I
had knocked the heatsink loose, or forgot to put a cable back on, or...).

I do love the "except fors." Memtest "always" (love that one too) finds the
problem "except for" the times it didn't.

But it likely will once you've determined it's likely.
 
Back
Top