One other way to do it is to put the memory in a PC that will take the
memory (I think Joy has a couple anyway) and use memtest86 -
http://www.memtest86.com/ - it requires no OS or even a hard drive, it
boots direct from floppy/CDROM, and will be able to test the whole
memory - i.e. it won't be used up by the OS.
Of course, this is not for the Mac though, but quite useful if you do
have a PC with matching memory slots, and so you can pull out the memory
of the Mac and put it in the PC and run memtest86.
Cheers- Piers
Jeff Walther wrote:
From: Nancy Haitz <[EMAIL PROTECTED]>
Date: Thu, 4 Aug 2005 21:32:50 -0400
Joy,
There are probably a number of ways to test RAM but I like a program
called RAMometer. It is part of Newer Tech's Gauge Pro group of
programs, and is a free download from Version Tracker here <http://
www.versiontracker.com/dyn/moreinfo/macos/15583&vid=61005>
After you download and install RAMometer, remove all of the RAM chips
except your original 64MB chip, which is your "known good" one. Then
add one of the four new chips. Then launch RAMometer and let it do
its thing. Overnight is always good, but you can run it anytime.
Let it run for at least 1000 passes/cycles. If you get any errors
the chip is not suitable for use. Errors are never acceptable.
However, removing and reseating a chip that caused an error is
usually a good idea.
Test each of your four new chips that way (alone with the 64MB chip)
To add a bit of explanation and one modification to Nancy's recommendation.
RAMometer and any other memory checker cannot test all of your memory,
because some of your RAM will be occupied by the operating system at the
time of testing. So if the only memory installed is the suspect memory,
you will not test all of the suspect memory, only a portion of it.
Hence, you should install your 64 MB DIMM in hopes that it will provide
the space for the OS while the suspect DIMM is tested. However, on other
machines, we (those who discussed this issue on other lists) were never
certain which end of the DIMM sockets gets used first and there are
indications that some memory is used at both ends.
So we originated the RAM Sandwich method (term coined by Peter in Japan,
now in Sydney). In this test method you need two known good DIMMs.
You put the known good DIMMs in your two outer DIMM sockets and the DIMM
to be tested in the middle. If you don't have two known good DIMMs you
can still get there from here.
Put your 64 MB DIMM in the first socket and one of your new DIMMs in the
last socket. Put a DIMM to be tested in one of the middle sockets. You
may wish to have some small labels (I cut up mailing labels) available
to stick to the DIMMs as it is easy to get them mixed up during testing.
The thing to remember is that if the test fails at this point, you do
not know the cause. A failure could be caused by the middle or by the
"unknown" end DIMM. However, if the test succeeds, then you know that
the DIMM in the middle is good, but you do not know if the DIMM at the
end is good. Working from these premises you should be able to certify
another DIMM as good (unless 3/4 are bad or something) and proceed to
test from there.
After inserting your DIMM sandwich, run RAMometer for about 1300
iterations. Most failures will occur within the first 200 iterations.
However, I have seen DIMMs that would consistently fail between 1200 and
1300 (always at the same number for a given DIMM), so at least 1300
iterations are necessary for a thorough test. This may require
overnight testing, unfortunately. If you are in a hurry (deadline on
your project?) you may wish to just run 300 iterations for now because
that will catch the non-subtle defects.
Once you have two known good DIMMs, just leave them at the ends and
insert your suspect DIMMs in the middle for testing. Run RAMometer and
see if they pass or fail. Use the "Shut Down Background Applications"
and "Run Continuously" settings. Ramometer will stop when it detects an
error. There is no way to set the number of iterations. You just have
to stop by from time to time and see how far it has gotten. It displays
the number of iterations on its window. Of course, you can time ten
iterations, multiply by 30 and have a pretty good idea of how long it
will take to run 300 iterations.
Even if you buy new DIMMs it is still a good idea to run this test on
them. On older machines 128 MB FPM DIMMs were $120 until Velocity
Upgrades came along and offered them for $80. The price fell from
there, and while their early shipments were good, later stuff had a high
failure rate and required testing. I found three of ten bad in one
shipment and seven of eight bad in another shipment. And while their
more reputable competitors did better, they shipped some bad memory
too. When the prices get low, quality often suffers even from the guys
who have been around forever.
Even if a DIMM does not cause consistent system failures, it may still
have a defect and this testing will probably catch it.
Obvious defects are the type where a cell (a bit) in the RAM is stuck to
0 or 1, regardless of what is written to it. So, if it's stuck at 1 and
your computer writes a 1 to it, everything is fine. The computer will
read back a 1 from that cell. But if the computer writes a 0 to that
location, it is still going to read a 1 from it later, which will cause
some kind of unintended result, the severity of which depends on what
that 0 represented. These are the kinds of errors that are probably
caught in the first 50 iterations of Ramometer.
Non-obvious defects depend on the surrounding cells. Physically, RAM is
a bunch of tightly packed structures made of layers of doped silicon,
oxidized silicon and metal. Their operation is dependent on electrical
charges in those structures. It is possible for the electrical charges
in surrounding cells to affect a nearby cell, though they shouldn't.
So there are sometimes subtle defects where an error is only produced in
a given cell, if the surrounding cells have a particular pattern of data
in them. It isn't possible in any reasonable amount of time to try all
the patterns of data that may occur, but my hypothesis is that Ramometer
changes test pattern as it runs extra iterations and this is why some
defects are not caught until late in the testing and are always caught
on the same iteration.
The good news is that these subtle defects aren't very likely to occur
or will seldom occur during use of your computer. Still, the chance
exists.
Jeff Walther
--
G-List is sponsored by <http://lowendmac.com/> and...
Small Dog Electronics http://www.smalldog.com | Refurbished Drives |
-- We have Apple Refurbished Monitors in stock! | & CDRWs on Sale! |
Support Low End Mac <http://lowendmac.com/lists/support.html>
G-List list info: <http://lowendmac.com/lists/g-list.shtml>
--> AOL users, remove "mailto:";
Send list messages to: <mailto:[email protected]>
To unsubscribe, email: <mailto:[EMAIL PROTECTED]>
For digest mode, email: <mailto:[EMAIL PROTECTED]>
Subscription questions: <mailto:[EMAIL PROTECTED]>
Archive: <http://www.mail-archive.com/g-list%40mail.maclaunch.com/>
iPod Accessories for Less
at 1-800-iPOD.COM
Fast Delivery, Low Price, Good Deal
www.1800ipod.com
