Memtest86+, ver, 1.65

[David Maynard]

JAD wrote:




It's sometimes necessary, such as when the fault can't be duplicated
with any other machine

In which case you're not troubleshooting a "component" you're
troubleshooting a system (and/or a design).

Of course, you wouldn't know that unless you *had* tested the components in
a separate known working machine or proper test bed.

or when there is no other machine.

Not having the proper test equipment begs the question.

At any rate, you're still not 'testing a component in the suspect machine'.

You'd know
that if you ever worked on something other than the most mundane
hardware, as a friend of mine has (some of that hardware is no longer
on this planet).

JAD may not be explaining it in the most easily understood manner but he is
quite correct and your friend, who has 'out of this world' equipment, would
agree with JAD.

If you have a system not working properly and you suspect component A is
the reason then how do you test your theory that it IS component A by
operating the suspect component in the very system that is not working
properly?

Answer is, you can't. You either replace component A and deduce from the
system then operating properly that the problem was, indeed, component A
(not 100% accurate) or you take component A to a known working system, or
better still a proper test bed, and verify it's operation.

The problem with the 'test it with memtest in the system' theory is the
deduction that if 'memory fails' then the memory module must be defective
when, in fact, there are numerous other things that could be the problem
with one of the most obvious being improper memory timings set in BIOS.
I.E. it can fail without 'the component (supposedly) under test' being 'bad'.

Memtest may give you a clue, that's what 'diagnostics' do, but the real
'test' is when you go out and buy another memory module and plug it in: the
replacement test. And you may discover it doesn't work either because
there's something else that's the problem. Even more confusing, the new
module might work yet there *still* be nothing wrong with the previous one
(an obvious reason might be the previous one not plugged in properly, or
dirty contacts, and the act of replacing 'fixed' that problem). And there
are many other more subtle possibilities, such as a noisy power supply that
some modules might tolerate better than others even though they all meet
specifications.

Which is why JAD suggested that whoever was testing with memtest send him
all their 'defective' memory modules.

 

[Conor]

after you duplicate the fault 50 times, whats next?

JAD showing he has no idea how to fault find...

I have a friend who saw the first space launch, is he an expert of space or
the technology it took to get a man there? No.

Same as you watching posts in this newsgroup for the past decade
then...

 

[Conor]

In which case you're not troubleshooting a "component" you're
troubleshooting a system (and/or a design).

Of course, you wouldn't know that unless you *had* tested the components in
a separate known working machine or proper test bed.

JAD doesn't actually know how to do testing. He knows the procedures
after reading posts in this group but hasn't quite grasped the process
of elimination yet.

 

[MaceFace]

I have a friend who saw the first space launch, is he an expert of space or
the technology it took to get a man there? No.

And neither are you. You also seem to be drunk or just barely
literate.

Longevity....hmmm my first Overclocking was on a 12mhz 8086 and was
attempting a whopping 16 out of it. This involved much more than booting a
machine and enabling and disabling bios features and buying a premade
cooling solution.

Holy 8284 F/*C pin, Batman. You need to do a lot better than that if
you want to impress anyone.

Besides the sentence was to provide an assumption example,
much like assuming I'm a tech of any kind in the first place.

Nobody assumes you are, but you put on airs to make people think you're
one.

This 'troubleshooting procedure' of testing components in the suspect (or in
most cases, KNOWN , bad system) and using it to determine what component to
toss and what to keep is...well...its not done, it makes no sense.

It's done all the time when people don't have a spare or compatible
computer. Troubleshooting with two identical machines is child's play
because you can simply swap parts between them until you find the one
that coincides with the problem.

 

[MaceFace]

JAD may not be explaining it in the most easily understood manner but he is
quite correct and your friend, who has 'out of this world' equipment, would
agree with JAD.

If you have a system not working properly and you suspect component A is
the reason then how do you test your theory that it IS component A by
operating the suspect component in the very system that is not working
properly?

By taking measurments or making substitutions? Just because a suspect
part can't be tried in another system doesn't mean a known good part
can't be tried in the original system.

I'd never reject memory if it only failed Memtest, but I would if the
voltages were normal, different BIOS settings didn't improve anything,
and other modules tested in the system passed Memtest.

Which is why JAD suggested that whoever was testing with memtest send him
all their 'defective' memory modules.

He just wants to sell defective memory on Ebay so he can pay for porn.
See his driver's license photo:
www.glowfoto.com/viewimage.php?y=2005&m=10&img=03-202113L&t=jpg&rand=1661&srv=img2

 

[David Maynard]

JAD doesn't actually know how to do testing. He knows the procedures
after reading posts in this group but hasn't quite grasped the process
of elimination yet.

Good example of why ad hominems are a logic fallacy because your insult
doesn't matter one way or the other to the fact that he's correct, regardless.

 

[David Maynard]

David Maynard wrote:




By taking measurments

And measurements taken by a defective system tell you what about a component?

Do you use a busted voltmeter to measure voltages? Do you use a CRT with a
dead red gun to measure the color quality of digital photos?

Measurements taken by a suspect system are, themselves, suspect.

or making substitutions?

In which case you are not testing 'the component' you just replaced and if
you had read the message before you snipped it all out you'd have seen the
examples I gave of some failure types that are 'solved' by replacement when
the component itself is not defective.

Replacing a component is not *testing* that component

Just because a suspect
part can't be tried in another system doesn't mean a known good part
can't be tried in the original system.

If you had read the message before you snipped it out you'd know that was
the first method I gave, as in "You either replace component A and deduce
from the system then operating properly that the problem was, indeed,
component A (not 100% accurate) or you take component A to a known working
system, or better still a proper test bed, and verify it's operation."

But replacing a component does not test the component that is no longer
there because you replaced it.

I'd never reject memory if it only failed Memtest,
Good.

but I would if the
voltages were normal,

Determined how and what did you calibrate it with?

different BIOS settings didn't improve anything,

I can give you tons of BIOS settings that won't 'improve' anything. Just
how did you determine which 'should' improve things in a defective system?
In fact, how did you determine that changing the settings actually does
anything in a defective system? Maybe the BIOS is buggy/defective. Maybe it
doesn't properly read the SPD in some modules.

and other modules tested in the system passed Memtest.

And, as I pointed out in the message you snipped "Even more confusing, the
new module might work yet there *still* be nothing wrong with the previous
one (an obvious reason might be the previous one not plugged in properly,
or dirty contacts, and the act of replacing 'fixed' that problem). And
there are many other more subtle possibilities, such as a noisy power
supply that some modules might tolerate better than others even though they
all meet specifications."

Module replacement is not a 'component test' of the thing that is no longer
there because you replaced it.

He just wants to sell defective memory on Ebay so he can pay for porn.
See his driver's license photo:
www.glowfoto.com/viewimage.php?y=2005&m=10&img=03-202113L&t=jpg&rand=1661&srv=img2

That's a good example of the 'poison well' logic fallacy because even if
what you said were true it doesn't alter the fact that he's right.

What JAD said was "no one in the business of troubleshooting, tests
components in a suspect machine, its counter productive."

So let's test your theory that he's incorrect by posing a scenario.

You take your machine to a shop for repair. The tech says he suspects it's
your memory and will test it (the component, the memory module) for you.

You ask how is he going to test it (the component, the memory module)?

He says he's going to plug it into a 'test machine' he's got that he
suspects isn't working right but, no matter, he'll use it to see if your
memory works right in the suspect machine that he doesn't know whether it
works.

And you're perfectly fine with this approach? You think this makes 'sense'?
To 'test' it (the component, the memory module) in a suspect machine?

 

[MaceFace]

And measurements taken by a defective system tell you what about a component?

Systems don't always fail completely, and even very wrong measured
values can often indicate that some components are likely normal.

Do you use a busted voltmeter to measure voltages? Do you use a CRT with a
dead red gun to measure the color quality of digital photos?

How you're being as ridiculous as a cable news talking head.

Measurements taken by a suspect system are, themselves, suspect.

In which case you are not testing 'the component' you just replaced

If everything works fine with the substitute, fails with the original,
then it's been tested.

and if you had read the message before you snipped it all out

If you don't want to be edited, be succinct.

Replacing a component is not *testing* that component

If you had read the message before you snipped it out

Learn brevity, Dr. Castro.

But replacing a component does not test the component that is no longer
there because you replaced it.

Is this a $1,000 component or a $50 one, and how much is labor?

Determined how and what did you calibrate it with?

DVM + scope for ripple.

I can give you tons of BIOS settings that won't 'improve' anything. Just
how did you determine which 'should' improve things in a defective system?

Memory timings, cacheing, pipelining, read-around, etc. Or just start
with the most conservative defaults and work up from there until
failure occurs again.

In fact, how did you determine that changing the settings actually does
anything in a defective system? Maybe the BIOS is buggy/defective. Maybe it
doesn't properly read the SPD in some modules.

How often don't systems read the SPD? Wrong or incompatible SPD
information is more likely.

And, as I pointed out in the message you snipped "Even more confusing, the
new module might work yet there *still* be nothing wrong with the previous
one (an obvious reason might be the previous one not plugged in properly,

It's plugged in right.

or dirty contacts,

They're clean.

and the act of replacing 'fixed' that problem).

The original was plugged in correctly and its contacts clean, too.

And there are many other more subtle possibilities,

Not at today's cheap prices for memory, power supplies, and
motherboards.

such as a noisy power supply that some modules might tolerate better
than others even though they all meet specifications."

A supply that noisy is defective, as is a circuit that can't tolerate
the worst noise a normal supply puts out.

Module replacement is not a 'component test' of the thing that is no longer
there because you replaced it.

Again, it shows if it's bad or incompatible.

That's a good example of the 'poison well' logic fallacy because even if
what you said were true it doesn't alter the fact that he's right.

Whatever you say, robot.

What JAD said was "no one in the business of troubleshooting, tests
components in a suspect machine, its counter productive."

So let's test your theory that he's incorrect by posing a scenario.

You take your machine to a shop for repair.

No, I don't, at least not a computer out of warranty - too risky
because survey after survey have found 70% of the shops misdiagnosing
even simple problems.

The tech says he suspects it's your memory and will test it (the
component, the memory module) for you.

You ask how is he going to test it (the component, the memory module)?

He says he's going to plug it into a 'test machine' he's got that he
suspects isn't working right but, no matter, he'll use it to see if your
memory works right in the suspect machine that he doesn't know whether it
works.

Don't present absurd contrived scenarios.

 

[JAD]

Conor................ the one who spends is whole life trying to be a 24hr
helpdesk wannabe and conjuring unverifiable statements LIKE ' When you have
OnBOARD VIDEO the ram memory spd defaults to a presupposed speed or some
such ridiculous bullshit. You have some nerve even commenting about 'reading
forums' to acquire your knowledge, You simply invent things as you partially
read what people write.


Sorry Dave, had to use your post to respond, he's been shitcanned for 3
years.

 

[David Maynard]

Systems don't always fail completely, and even very wrong measured
values can often indicate that some components are likely normal.

May, might, sometimes, often, could be... The point is you can't know.

How you're being as ridiculous as a cable news talking head.

Not at all. They're obvious to illustrate the point.

If everything works fine with the substitute, fails with the original,
then it's been tested.

No it hasn't. The combination has been tested, not the individual component.

If you don't want to be edited, be succinct.

The edited parts dealt with each one of your arguments.

Learn brevity, Dr. Castro.

Here's brevity for you, you're wrong.

Is this a $1,000 component or a $50 one, and how much is labor?

The issue wasn't whether it was 'worth it' to test a component; the issue
was how do you test it.
<snip of examples>

You're trying to argue that you've checked each one of the examples but
examples are just that, examples, and not the totality of what might be a
problem.

You're also trying to argue that you've checked 'every other possibility',
in essence turning the 'suspect' system into a 'non suspect' system so it's
suitable to the test, but, besides that being impossible, it would be a
heck of a lot more efficient to simply test the suspect component in a
known working system or, better still, a proper test bed.

Or replace it and go on. But, again, that begs the issue of testing the
component.

Not at today's cheap prices for memory, power supplies, and
motherboards.

That is a total non sequitur. The 'cheapness' of something has nothing
whatsoever to do with whether it could be one of the "other more subtle
possibilities."

You may decide it isn't worth testing one, or more, components because it's
easier/cheaper to simply replace them but that begs the question of testing
the component.

A supply that noisy is defective, as is a circuit that can't tolerate
the worst noise a normal supply puts out.

No kidding, Sherlock. The point was that either, as well as other things,
can be a problem so testing a component in a suspect system doesn't tell
you if that component, or something else in the system, is bad.

Again, it shows if it's bad or incompatible.

It may show you that it doesn't work in the particular system. It does not
tell you why nor that it's necessarily bad nor that something else in the
combination isn't bad.

Whatever you say, robot.

Do you work real hard at coming up with stupid lines or does it just come
naturally?

No, I don't, at least not a computer out of warranty - too risky
because survey after survey have found 70% of the shops misdiagnosing
even simple problems.

Irrelevant to the scenario.

Don't present absurd contrived scenarios.

It is a scenario that accurately describes the notion you're trying to
defend: that testing a component in a suspect system is perfectly fine.

The fact that it shows just how absurd that notion is simply demonstrates
it's effectiveness.

 

[David Maynard]

Conor................ the one who spends is whole life trying to be a 24hr
helpdesk wannabe and conjuring unverifiable statements LIKE ' When you have
OnBOARD VIDEO the ram memory spd defaults to a presupposed speed or some
such ridiculous bullshit. You have some nerve even commenting about 'reading
forums' to acquire your knowledge, You simply invent things as you partially
read what people write.


Sorry Dave, had to use your post to respond, he's been shitcanned for 3
years.

No problem.

I'm just surprised that such a simple, and obvious, statement can result in
such nonsense.

Well, maybe surprised isn't the right word.

 

[Conor]

Sorry Dave, had to use your post to respond, he's been shitcanned for 3
years.

ROFL...

3 years? Is that, like, supposed to mean something?

 

[JAD]

No problem.

I'm just surprised that such a simple, and obvious, statement can result in
such nonsense.

Well, maybe surprised isn't the right word.

Its GNUism extremists...all things GNU or LINUX are infallible.

 

[Shep©]

On 3 Oct 2005 20:33:46 -0700 As Androids Dreamed Of Electric Sheep and


Software Mem Testers suck.
A recently discovered tribe in the deepest Congo refused to download
or run them on their lap-tops preferring to swap known good ram sticks
they found in the pocket of a missionary who apparently tasted better
with onions rather than garlic.Hmmmmmm.Tasty.I'd have preferred a
Desciple,nearer-to-the-bone.MuhHaaaaHaaaa

 

[David Maynard]

Its GNUism extremists...all things GNU or LINUX are infallible.

What does 'GNUism' have to do with supposedly 'testing' hardware components
with a broke system?

 

[JAD]

What does 'GNUism' have to do with supposedly 'testing' hardware components
with a broke system?

The GNU clan was behind memtest8x, at least last time I looked. So I figure
even though memtest86 is useless, they will defend it none the less, based
on blind loyalty to their leaders. What other reason can there be to blindly
disregard the obvious? Maybe Way too many modules thrown out, to justify
ignoring the truth? Of all the things to pick, to disagree with me on, some
chose this topic. Pretty cut and dry when you boil it down.

 

[Guest]

[ 3,000 words of useless infighting deleted ]

This must be what it's like at FEMA.

 

[larry moe 'n curly]

Software Mem Testers suck.

Except for being slow, how do MemTest86, Gold Memory, and Ultra-X RST
"suck" at testing memory? 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.

So why do you believe that software-based memory diagnostics are bad?
Do you have any proof to back up your opinion?

 

[David Maynard]

The GNU clan was behind memtest8x, at least last time I looked. So I figure
even though memtest86 is useless, they will defend it none the less, based
on blind loyalty to their leaders.

Oh. I see the 'connection' then.

What other reason can there be to blindly
disregard the obvious? Maybe Way too many modules thrown out, to justify
ignoring the truth? Of all the things to pick, to disagree with me on, some
chose this topic. Pretty cut and dry when you boil it down.

yup

 

[David Maynard]

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).