Cannot upvote enough. At this density, and considering caches will have persistence of days (if not more) in the main memory, random errors become a major issue. ECC should have became a standard in system memory 5 years ago already.

Wait is that true? There is no error correction in system memory? That sounds like a huge waste. Usually with coding not only reliability increases but you can decrease power consumption a lot too (so you're not "fighting the noise" with power only).

Yes, exactly true. Some libraries (like innodb) actually checksum all contents in memory to self-detect when corruption is happening. Most applications and libraries trust system memory too much and can read corrupted data at any given time.

Another fun way to get corrupted memory is to have some data swapped to disk, but have disk corruption, then have the corrupt disk data restored to memory. Bam. Instant invalid data in memory, but not caused by memory.

Many hashes are fast these days and should be used as checksums in more places since ECC isn't as common as it should be (and ECC doesn't detect all errors anyway).

> and still no ECC support, sigh

Are there any technical reasons not to have ECC by default, or is it just market segmentation?

Market segmentation. Core i{5,7} with ECC support is sold as Xeon E3.

For a while some of the Xeon E3s were the thing to buy, as they were sold at lower prices than the equivalent i7 CPUs (Xeons with 4 cores+HT and lots of cache were sold at the same price as the quad or dual+HT i5s), but this was "fixed" and now the cheap Xeons are crippled (no HT anymore).

What about motherboard support? I can't usually find any motherboard with ECC support that also has decent onboard sound...

Don't know about the quality of the support†, or what "decent" onboard sound is, but Supermicro sells a bunch of boards that support 1 or 2 Xeons (and generally also support consumer chips), ECC and have onboard sound. E.g. for the low, low price of $289 this board http://www.newegg.com/Product/Product.aspx?Item=N82E16813182... will support two processors, up to a half terabyte of memory, and has a Realtek ALC888 for 7.1 channels of sound.

†I'm using a one processor chip X9SAE to type this with, with HDMI output with sound included to my receiver and then monitor.

ECC support + decent onboard sound seems like a niche feature combination (at least in the Intel world where ECC support means buying a Xeon and a compatible server/workstation motherboard). Some AMD consumer boards do support ECC if you want to go down that route (e.g. http://www.asus.com/us/Motherboards/M5A97_PLUS/specification... ).

Not sure of your particular usage case but wouldn't it be just as easy to pick up a cheap (or decent) sound card that would meet or beat anything onboard could do? I personally tend to stick with onboard because it does what I need (sound for music and movies) and I use external sound interfaces when I want to mess with anything requiring more sound performance/options (like recording or making my pitiful attempts at producing music).

ECC memory has a small performance overhead, and is slightly more expensive (e.g. 12%).

It is segmentation for sure -- the chipsets and processors can easily support it -- and many of the people throughout this thread really should only be looking at Xeons. If 64GB of RAM and non-ECC memory is really such a problem, which it is for a vanishingly small percentage of users, go with a workstation chip at a small premium and have it all.

It's notable that effectively no mobile devices use ECC memory. Tablets don't. The vast majority of desktops don't. If you believed the rhetoric, these should all be crashing and destroying lives regularly. It turns out that ECC comes into play very, very infrequently. I would never buy a server that didn't have ECC, but on my desktop it just really doesn't matter that much.

What's the performance overhead of ECC come from? I know registered memory has a small but measurable latency penalty, and ECC modules are often also registered, but a simple parity check in the memory controller should be a pretty fast circuit.

These days ECC testing is supposed to be integrated into the CPUs.

Enthusiast testing seems to support this with overhead being <0.5% even for Reg ECC:

https://www.pugetsystems.com/labs/articles/ECC-and-REG-ECC-M...