Scot Finnie, a “Windows Expert” wrote an article for Computerworld in which he describes his 3 month experiment using only a MacBook Pro. One of the comments he makes is,
I haven’t had a spontaneous reboot since the moment I pulled the [bad] RAM SIMM, the second day I had the machine. It’s been about six weeks. Apple computers are picky about RAM.
What surprised our dear friend Scot is that Apple hardware seems to care about the quality of RAM it is given. He is of course, correct. However, what he fails to note is that EVERY computer is quite finicky about RAM. Bad RAM will cause any Operating System running on any hardware to behave in undesirable ways.
During the legacy Mac OS days, when stability on Mac or Windows was not a thing to be depended upon, I remember joining a mailing list specific to BSD UNIX, which I was getting acquainted with. Another list member described a type of crash his system was experiencing. I thought it a bit presumptive when others pointed out his problem was almost certainly bad RAM. It was as if they were saying, “the problem is not our OS, it’s your hardware that is junk!” That scenario played out dozens more times during the years, as guys with only PC experience ventured into the land of UNIX where servers run for years and hardly ever crash.
The difference is one of perspective and requires a paradigm shift. Scot’s experience is one where frequent crashes are still commonplace. Now Scot has tasted a computing environment where six weeks, or six months without a reboot is common. It’s not that Apple computers are more picky about RAM. It is that you tend to notice when your system goes from rock solid dependable to sporadically crashing, which it had never done before. Scot, we welcome you to a brave new world.
PS: NewEgg has great prices, great service, and ample options for buying RAM for any computer.
We recently put together five new 1U supermicro white box servers. Each used four 2GB PC3200 modules from some outfit called “Patriot Memory.” The machines were to be used for a Redhat Enterprise Linux cluster, but were initially burned in as WindowsXP/3DSMax render nodes. They crashed a lot as XP nodes, but the Windows IT fellow who put them together said not to worry, that it was just XP. Low and behold, they keep crashing after I set them up as a Linux cluster, usually with a “Machine Check Error” message on the console. So I run memcheck86+, but alas, even after three or more days of memcheck running, I can’t find the bad RAM. Only after I made a stress testing script that simultaneously compiled the linux kernel, glibc, xorg-x11, ran various gromacs simulations and a disk benchmark all at once could I get the RAM to consistently fail. The RAM had to be running 128-bit interleaved (had to tested in pairs), and the box had to run at full load with complete memory usage for at least a few minutes before failure. We bought four spare Kingston 2GB sticks with identical specs and ran them under the same stress test on the same machines to see if it could be something besides the RAM, but no – the Kingston RAM never failed, not once. We ultimately determined that a full 9 out of the 20 Patriot RAM modules we had simply were not up to spec and were not reliable.
We RMA’d the bad modules but after the first of the modules Patriot sent us back in return failed I exceeded my bad RAM threshold, had to smack the Windows IT guy upside with head with my LART and demand that “Patriot” RAM never ever ever get within twenty feet of any of my clusters.
Someone please link to this comment as “Patriot RAM”, or “Bad RAM” or “RAM failure”. Pretty please.