[conspire] Parts is Parts

[Rick Moen]

Quoting David Fox (dfox94085 at gmail.com):

> Kinda hard to believe you can get 1 *gig* ram sticks for $20. I won't
> bore you with stories about how expensive RAM used to be :).
> 
> The RAM spec on these PQI units also bothered me. But for a "light"
> user (Kai's Dad, specifically) this may not be (pardon the pun) all
> that crucial.

Probably not crucial -- but I've often wondered how much bad RAM is in
use that its users have no idea is bad.  I also have to wonder about
quality loss with falling prices and rising RAM densities.  

Back around 1995 when the Intel Triton motherboard chipsets came out
lacking memory parity support (and were a big success because of the
better cache pipelining and support for EDO), and we were all told "Oh,
you don't really need a parity bit on RAM sticks, any more", I just
didn't buy it, and have tried to make a habit of stress-testing any RAM
I have the least doubts about, at least -- because my experience with
(say) floppy disks and hard drives is that, when prices go through the
floor and data densities are still rising, one can expect quality
problems.

Note that bad RAM can have a much more pernicious effect than does bad
storage media:  The firmware and OS-level routines for testing and
mapping out bad disk sectors during regular operations are pretty good;
the corresponding situation for bad RAM is that there simply _aren't_
any.  The result is that you get progressive, silent, unnoticed
corruption of all data that pass through that stretch of RAM during any
data operation including disk buffering.

Progressive, silent data corruption is, in short, really bad juju.  I
like my data, and would, whether I were a heavy computer user or not.


> $150 I think is what I paid for the second stick of 512 meg, the first
> being 256 meg. Short of pulling the chips and examining them, I have
> no idea what brand they are, and they've performed perfectly. I've
> even tried my hand, once upon a time, running 'make -j' on the kernel,
> but I only went as high as make -j 25 IIRC. 

You want to keep increasing the number while watching the "si" and "so"
fields on /usr/bin/vmstat's report of swap activity:  Those are the
swap-in and swap-out columns, so when those start spiking, you've maxed
out RAM by using substantively all of it for your compile processes.

_Not_ taking that step (an error I've myself made) means any clean bill
of health you arrive at for your RAM can be misleading, as your testing,
in fact, skipped some of the RAM.

> I managed to ramp up the load average on this box once to
> over 100, and it didn't fall over. :).

See, load is good, here, but is a side-effect and technically not
primarily what you're trying to achieve:  You mostly want to ensure that
you're exercising _all_ of the RAM, during your testing.

It'd be unfortunate, for example, to test the lower half of memory
addresses, but in fact it's the RAM at higher addresses that's
defective.  You bless the machine as healthy and put it back in service,
OO.o and The GIMP keep falling over (or random apps any time you have
quite a few things loaded), because you're suddenly exercising _upper_
RAM addresses, and you're back where you started.