Date: Wed, 29 Dec 1999 12:57:49 -0500 From: Graeme Tait <graeme@echidna.com> To: "Kenneth D. Merry" <ken@kdm.org> Cc: Michael VanLoon <MichaelV@edifecs.com>, Mike Smith <msmith@freebsd.org>, Lance Costanzo <lance@costanzo.net>, freebsd-hardware@freebsd.org Subject: Re: ECC RAM useless with FreeBSD? Message-ID: <386A4B9D.A9F89749@echidna.com> References: <8070C3A4E99ED211A63200105A19B99B317471@mail.edifecs.com> <19991228215756.A94267@panzer.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Some memory errors are transient, radiation-induced events. The likelihood of such errors is increased by the decreasing storage cell charge employed with increasing memory density. This problem will be more serious at high altitude because of increased cosmic radiation. As an extreme case, I believe that laptops used in orbit on the Space Shuttle crash of order once a day from radiation events. Such errors are not memory chip problems per se, and could be a good reason to enable ECC when available. "Kenneth D. Merry" wrote: > > On Tue, Dec 28, 1999 at 20:54:46 -0800, Michael VanLoon wrote: > > From: Kenneth D. Merry [mailto:ken@kdm.org] > > Sent: Tuesday, December 28, 1999 8:36 PM > > > > >FWIW, I generally run with parity detection turned on, but not ECC, since > > >I've heard (i.e. I haven't looked in any Intel datasheets to verify this) > > >that there may be a performance penalty for running with ECC turned on. > > > > > >You could probably verify the performance penalty by doing a dd test for > > >memory bandwidth with ECC enabled and simple parity checking enabled. > > >(e.g. "dd if=/dev/zero of=/dev/null bs=1m count=1024") > > > > There is a performance penalty, but it's very slight, especially if you have > > decent cache (any modern processor (PII, PIII, Athlon) or a decent Super-7 > > motherboard with a K6). > > > > Parity only detects one-bit errors. ECC can detect two-bit errors. You're > > doing yourself a disservice by buying that more expensive memory, then not > > really using it, especially on a server (where reliability is much more > > important than a slight performance increase). I seriously doubt you could > > determine the performance difference between having it on or off, except > > with some sort of very specific benchmark. > > I've never had a memory problem (and I've had a number of memory problems) > that wasn't detected with simple parity. Maybe I'm just lucky. > > If you have a slightly less modern processor (like a Pentium Pro), I think > the performance loss can be around 10% or so. Unfortunately I'm not in a > position at the moment to do the dd test above, so I can't say for sure, > only what I remember. > > > And, does that hardly discernable performance loss make up for the time you > > lose when your machine crashes, or you have to track down some malfunction > > that is simply a flipped bit? > > I suppose I've never had a 2-bit error. > > Another way to look at it is that I'd rather be notified of memory > problems, so that I can then turn on ECC to work around them, than have ECC > silently work around the problem. > > If I had faster machines, and if we had some method of notifying the user > when there are bad bits that get ECC corrected, I probably would run with > ECC turned on. As it stands, though, you won't know about a 1-bit memory > problem if you turn ECC on. > > Ken > -- > Kenneth Merry > ken@kdm.org > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hardware" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?386A4B9D.A9F89749>