I rely on you Jeff to tell us your personal
recommendation on the best brand to buy. One that has
had the fewest failures. I see a ton of ads out there-
all claiming to be the best.
Signed David(with the anonymous B&W)
--- Jeff Walther <[EMAIL PROTECTED]> 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
>
=== message truncated ===
--
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
