ECC has essentially no downsides but, as I said, there's no point in going out of your way to have it on a rip library.

You generally want it on servers, especially largish ones because servers are usually used to store data you don't want to lose. Traditionally, people have been putting all the data that matters on servers that can me made more reliable and managed better (especially as far as backups are concerned) than desktops.
The more data, the higher the chance of losing some and the higher the impact of any problem affecting the whole system. Like I said, I don't understand this market but I would have thought someone who wants 12TB of storage and who spends >1K on it has valuable data and would therefore value reliability. But maybe not.
EDIT: 24/7 is obviously a factor as well

@ilovejedd
Yes, I would prefer to use ECC on all my computers. But do you know of any laptops with ECC support? And where do I get ECC SODIMMs for them?
I said in my first post that "I don't think ECC is a must-have". Sometimes it is, but probably not for a home server. It depends on what the computer does.

matt_garman asks: "How do you advertise the ECC feature without scaring away people who don't want/need it, or don't know what it is?"
Asus simply states that ECC is supported in the specs of its mainstream boards. Those who want it see it's there and those who don't don't notice.
As to actual advertising, check HP's brochure on their new Proliant. It apparently tries to sell a "real server" to people who don't have one.

EDIT:
kaotikfunk writes about ECC: "Intel is using this as a differentiating feature for Xeon processors, which rules out most lower end CPU's. I hope this changes in the future."
Hope doesn't do anything. All you need to do is to tune out the Xeon chorus and pay attention. Clarkdales have always supported ECC. Or at least they're supposed to.

[quote="HFat"]kaotikfunk writes about ECC: "Intel is using this as a differentiating feature for Xeon processors, which rules out most lower end CPU's. I hope this changes in the future."
Hope doesn't do anything. All you need to do is to tune out the Xeon chorus and pay attention. Clarkdales have always supported ECC. Or at least they're supposed to.[/quote]

Yep, hope does nothing. I instead voted with my wallet, and chose AMD for my low-end server. Other builds that I looked over with Intel were using low-end Xeons which cost more than the AMD hardware I was buying.

This other WHS build article indicates it is a Xeon-specific feature: "Intel’s Lynnfield based Xeon CPUs have one major home server feature that consumer CPUs like the Atom and Clarkdale lack, ECC support"
http://www.wegotserved.com/2010/07/27/s ... rver-vail/

I could be wrong, but that's what's commonly published. Intel's ARK has a specific field for it as well:
Xeon X3430: http://ark.intel.com/Product.aspx?id=42927
Core i5-650: http://ark.intel.com/Product.aspx?id=43 ... LBLK,SLBTJ

Anyway - the ECC debate can go on and on. As a developer, I hate debugging issues that turn out to be single-bit errors. I pay the little bit extra on my RAM to avoid it in machines that are run 24/7. My gaming rig - I don't care.


In other news - HP has an interesting server that's pretty similar size to this build. It uses a low-voltage, low-clocked dual core Athlon II, unbuffered ECC memory, 4 internal drive bays, and an eSATA port. If it's quiet, it could be a good prebuilt alternative.
http://h10010.www1.hp.com/wwpc/us/en/sm ... 48009.html

[quote="andymcca"][quote="Monkeh16"]It's a mystery to me, because that makes no sense whatsoever. ECC does not make things compress better! Data is data, ECC doesn't change that.[/quote]

I think his point was that bit errors are much more noticeable in information-dense (compressed) formats. A single bit error could ruin an entire archive if proper safeguards are not in place. The same error might result in a minor video glitch in your high-bitrate video file. And in a bitmap it could be a single pixel error you might never see.
Not sure what sort of archiving he was doing, but it sounds like he was noticing errors because of high compression with limited parity.
Disclaimer: I am not familiar with the specifics of modern compression formats. I have no idea how much parity (or what type) they have.[/quote]
I think before you try and figure out a rational explanation for what he said, you may want to read some of his other posts. The ones where he says heatshrink makes his fans run faster and that certain CPUs can't display photos correctly.

E: I think I know why BBCode isn't working. I'm think it's a permissions problem, it works in certain forums but not others. No offense to you guys, but phpBB3 is not a minor upgrade, you may want to take more time staging it before deploying..

Matt, the vendor is most likely conjecturing on why ECC is not supported (or explicitly supported) by most mitx board makers. His company sells lots of mitx products; very very few support ECC memory. His response to learning about the new HP microserver: "Holy…That’s a lot of gear for $329!"

Perhaps you'd like to lead a search for all mitx boards that support ECC RAM that could be worked into an addendum about the topic in the server build article?

HFat:
>ECC has essentially no downsides but, as I said, there's no point in going out of your way to have it on a rip library.
>
>You generally want it on servers, especially largish ones because servers are usually used to store data you don't want to lose. Traditionally, people have been putting all the data that matters on servers that can me made more reliable and managed better (especially as far as backups are concerned) than desktops.
The more data, the higher the chance of losing some and the higher the impact of any problem affecting the whole system. Like I said, I don't understand this market but I would have thought someone who wants 12TB of storage and who spends >1K on it has valuable data and would therefore value reliability. But maybe not.
>EDIT: 24/7 is obviously a factor as well
>
>I said in my first post that "I don't think ECC is a must-have". Sometimes it is, but probably not for a home server. It depends on what the computer does.

With today's platter densities, you don't really have to spend >$1K to get a 12TB server. Figure $600 for 6x 2TB drives, ~$100 for mobo, ~$50 for CPU, $50 for case and $100 for PSU and you're just at $900 for hardware.

By the way, I do have 12TB of storage on my home server (started with 3TB and added drives over time) and no, it doesn't have ECC RAM. Of the data stored in the server, there's less than 50GB that I'd consider irreplaceable and those are duplicated among a number of computers. I built the server specifically for media storage for a whole house HTPC/extender set-up which, I reckon, is one of the popular reasons people are building/buying home servers. Granted, the rebuild I'm planning will have ECC memory but only because the motherboard I chose already supports it. Sure, ECC's a nice feature to have but I'm not going to limit my motherboard/CPU choices just to have it.

@kaotikfunk
I delved inside Clarkdale specification sheets and found the following:

"The Integrated Memory Controller (IMC) supports DDR3 protocols with two independent, 64-bit wide channels each accessing one or two DIMMs. The type of memory supported by the processor is dependent on the Intel 5 Series Chipset SKU in the target platform:

* Desktop Intel 5 series Chipset platforms support non-ECC unbuffered DIMMs only and do not support any memory configuration that mixes non-ECC with ECC unbuffered DIMMs.

* Server and Workstation intel 3400 Series Chipset platforms support ECC unbuffered DIMMs. Workstation Intel 3400 Series Chipset platforms also support non-ECC unbuffered DIMMs. Workstation Intel 3400 Series Chipset platforms do not support any memory configuration that mixes non-ECC with ECC unbuffered DIMMs."

If I'm understanding this correctly, all Clarkdales can support ECC memory and it's the chipset that determines whether ECC is supported or not. I guess it's just a matter of not many people trying it.

Intel's ARK used to say that Clarkdales support ECC. Now it doesn't say anything. On the other hand, it has no problem stating that non-Xeon Lynnfields don't support ECC. Lynnfields have different memory controller than Clarksdales. Meanwhile, (some) motherboards makers say that Clarkdales (or at least the i3 and Pentiums) actually require ECC RAM on (some) ECC-supporting boards.
One might need to test with a DIMM that has a lot of correctable errors to determine for sure if ECC works in that configuration. Error reporting might not be supported while correction still happens. That or Intel has found a way to require ECC RAM while making it run like regular RAM.

Here's a mini-ITX motherboard with ECC functionality:

Lippert Thunderbird-E3100

http://www.lippertembedded.com/en/lippe ... e3100.html

Cool board - unfortunately, prices start around $950.00!

Pretty much all of the old hardware I've got around here supports ECC, starting with a pile of Intel 430 HX chipset Pentium motherboards, and my old favorite 440 BX Pentium II motherboard. I've also got some old P3's with ECC RAM. The only questionable systems were the VIA chipset socket 370 boards because the chipset documentation is nil. After that, I migrated to AMD systems which are generally much more ECC friendly. Until Intel moved the memory controller onto the CPU, the only way to get documented ECC support on the Intel side was to use a motherboard with an Intel server chipset. My latest build was AMD because of cost, and because I wasn't able to decipher whether or not a Xeon CPU was needed for ECC support.

Back in the days before I used machines with ECC RAM, I'd get crashes due to memory parity errors a few times a year. Without parity, something would be just be getting silently corrupted.

My current primary machine uses an AMD socket 754 motherboard. It's getting fairly frequent machine check errors, but fortunately they all seem to be correctable. I'll swap in a spare AM2 board that I freed up when I upgraded another machine as soon as I get some spare time.

I regret that I'm late to the party, but regarding the whole ECC/RAID argument for WHS...

I've heard all these arguments before and to understand why these things are not supported, you need to understand the target market. This OS was designed for OEMs to build a small, cheap and stable platform for whole home storage and managed backups/security. ECC platforms tend to be too expensive, too large or too much overkill for the low I/O necessary for these tasks. To overcomplicate the OS would be detrimental to most OEMs who need a low-cost/complexity option for an initial market offering. Those who are capable of (and comfortable) managing massive amounts of complicated hardware and backup/RAID options would be better off to use Win2003 combined with RAID and/or ECC hardware.

WHS (v1) was not meant to handle more than a few HDDs as evidenced by some of the bugs in the DE-Migrator service. There are lots of people though who have made it work with very large HDD arrays with no problems. There are others (including OEMs) who have made it work with an Atom and 2 small hard drives. That speaks to the robustness of the WinXP/2003 core of the OS.

However, the main reason that RAID is not supported is the what Drive Extender works. The primary (C:) drive holds what are called "tombstones" for the rest of the DE pool. These tombstones are constantly changing as more data enters the pool, whether through file share storage or backups. To clone the pool would have no meaning unless everything in the tomestones reference those specific locations on the drives holding the data.

In reality, the most effective way to protect the data on the WHS pool is to enable duplication and run a RAID-1 for the primary. This would protect the weakest point of the pool as the Primary partition cannot be backed up by WHS itself.

Many of the issues with WHS v1 will be resolved with v2 (known for now as Vail) which is based on Win2008 R2 (Win7 core). The extender and backup services have been revamped to be more efficient with CPU cycles when dealing with large files and arrays. A 64-bit CPU is mandatory to allow better memory management, and an App Store (of sorts) for Addins is included to ease the process of adding functionality.

Mainly, I'm excited that it will finally get rid of the disgusting dual-install of the original, where a user was required to use the old DOS-blue install environment before working in the full-GUI portion of the install. It made it overly difficult for homebrew-ers to use all SATA without slipstreming the drivers into their own install DVD.

ECC and RAID are great and definitely have their place, just not where the WHS was originally targeted...

It's worth mentioning that WHS v2 (a.k.a Vail) will have the ability to check (and correct) errors on your HDDs. Not as good as ZFS, but a lot better than WHS v1.

Interesting but note that this does not address the issue of corruption caused by memory issues, only corruption caused by disk issues. In order to adress both, keep hashes of your static data. Dynamic data is more difficult to manage securely.

I'm surprised by jhhoffma's welcome explanation of what WHS is about. Based on that post, WHS (v1 anyway) seems difficult to secure and suited to small servers sold fully-built, not mid-sized self-built servers such as the one Mike designed.
Building Mike's server is a good bit harder and not necessarily cheaper than buying a box with ECC capability by the way. The advantages of Mike's build are size, low idle electricity consumption compared to how powerful the server is and especially silence.
I wish you would all tune down the baseless OS advocacy. It's easier is to use what you have experience with but that doesn't make what you have experience with easier for everyone.
Nor is RAID particularly difficult to manage. One of its main advantages is in fact to make one's life easier in case of a drive failure.

A lot of the discussion in this thread has been about ECC and what does/doesn't support it. Here is a newsflash:

IT IS NOT THAT SIMPLE!

I tried to find out what hardware supported ECC and found out a lot of nasty stuff. A lot of the vendors claim ECC-support when the hardware can support running modules of ECC-memory in non-ECC mode. Actually, all the mobomanufacturers I contacted gave similar answers. "We don't actually support ECC. When we write that our hardware supports ECC, we mean that a memorymodule supporting ECC can be inserted and it will be operated in non-ECC mode"

So there you have it, no matter what is claimed in the spec. sheet, DO NOT TRUST IT!

I can not emphasize that enough. Also, I had to repeat the question about 10 times with each company to recieve an answer relevant to my question, they were all reluctant to admit that this was the case. So far, I have yet to find a mobo that actually supports running ECC-modules in ECC-mode.

morgue -- thanks for the report and caution about ECC.

That's interesting. I assume you mean consumer mobo? How about those that support bitkill or whatever it's called?

Consumermobos only, I did not contact Tyan nor Supermicro. I did not ask about chipkill. I got frustrated and mad when one after one they began confessing and I gave up my hopes on ECC

Edit: I assume you meant chipkill? Bitkill I have never heard of

Something else worth mentioning. Intel and AMD ECC-support should be separated if this discussion is to continue since one relies on the mobo's memorycontroller and none on the CPU whilst the other relies on the CPU and the mobo to transmitt those signals to the memory.

I agree... but do not trust what vendors say when they deny supporting ECC either. You're being too trusting.
Some claim to have verified ECC support on consumer boards such as Asus' A8N-SLI.
Also, I would hope one can trust server boards featuring expensive chipsets and/or supporting expensive CPUs when they claim ECC support. I'm not so trusting about HP's new small server based on laptop gear however.

I tend to trust companies when they admit to something bad about themselves. The way I see it, they have very little motivation to lie about it.

Although now that you mention it, if for example gigabyte were to also manufacture serverboards that they have a larger profitmargin on, then they might profit from giving such answers...

Edit: Also, the knowledge of the support varies. A LOT. Some don't seem to have a clue about anything except their answers taken rendomly from the FAQ. The only way to get a real answer would be to reach the developers directly.

Yep, that's the one.



So if we were to split the disucussion, which has 'proper' ECC support? Intel or AMD? I'm guessing AMD? But both Intel and AMD have IMCs now, don't they?



There are ways of getting drives to spin down. Just not very convenient. I assume you'd leave a drive connected to a computer because you access it semi-frequently, but if you spin it down, you would take 10-30 seconds waiting for the drive to spin back up when accessing data.

I wouldn't call it 'proper'. It is more about the location of the parts responsible. Intel has had their memorycontroller in the chipset (mobo) whilst AMD has had theirs on the CPU itself. It has been necessary for the Intel CPU to support ECC but the mobo and chipset does the work. AMD however has their MC integrated and the mobo needs to transfer the signals to the memory.

I am not going to discuss which one is better, simply conclude that they are quite different. Also, the above statments does not include Intels newer platforms as they have integrated the memorycontroller into the CPU. (A guess would be that this is the better choice since they both seem to have settled for this solution)

Edit: I didn't ask any of the companies about s1156, s1366 or any newer or upcoming platforms (s1155)

You can always check a mfg's manuals. The first 2 AMD-chipset motherboards I checked at usa.asus.com (M4A88T-M, M4A78LT-M) show ECC configuration in their manuals. It's not just "ECC DIMMs are supported", it actually shows you how to enable ECC.

Though I question that validity of some manuals - they're often reused across a number of products.

Some of them have an option to turn "on" ECC, which really means to turn on ECC-support, which is their way of saying "If you enable this option, your ECC-memory will 'work' (not necessarily in ECC-mode)"

Might not be the case with the one you are mentioning, but then again it could. I can not make any specific claims about the one you mentioned but it seems to be hard to find mobos that actually support ECC. Gigabyte were the nicest, they said that they couldn't give me a list but that I could return to ask about whether a specific board fully supported ECC.

EDIT: Checked it out, indeed it has more options than on/off... Disabled/Basic/Good/Super/Max/User... Weird

Do you mean that you'd need non-ECC RAM to get to the BIOS only to change that setting before switching to ECC DIMMs? Really? We've seen stranger things of course but still...

I suppose that's possible. Do you own any boards that "support" ECC in this way? I'm curious what Memtest reports.

The manuals for both Asus boards I mentioned above list ECC support like this:

To me, this suggests that it's something beyond simply allowing the use of ECC DIMMs.

Ultimately, I suppose it will come down to a consumer buying and testing the boards. And reporting their findings!


I'm not sure that the location of the memory controller is reason to split discussion. As long as we understand that ECC function requires support from the memory controller (wherever it is), DIMMs, motherboard traces, and BIOS.

For anyone looking for more info in general, here is an overview of memory errors, parity and ECC written for a non-engineering audience. The site hasn't been updated in a while, but the principles haven't changed much.

http://www.pcguide.com/ref/ram/err.htm

I understood and believed you once I saw that there were more options. That raises more questions though. I just gave up midway through my research. Does this mean we have to go through all mobomanuals since they are a more direct link to the developers than the actual supportstaff

Whoops - I didn't see your edit!

Disabled/Basic/Good/Super/Max/User
I have never heard of these different levels of ECC. First, I got all happy that they might have hidden something from me but it is a bit unsettling. What does it mean? A more aggressive errorcorrecting code? What would be the downside to using the Max-setting? I have never heard of any ECC-modules that support ECC-Super...

These are basically presets. Here's a clip from my Biostar board's manual. It uses the same preset names.

After you pick a preset (Basic, Max, etc.) various sub-menu options are enabled/disabled for additional tweaking. I don't remember exactly what each preset adjusts, but it has to do mainly with how often memory is scrubbed for errors.

I believe I explicitly stated 'in a sane manner'.

I found a relatively inexpensive microATX board with a non-Xeon Intel processor that supports (truly supports) ECC. I'm about to buy it. HFat asked me to post my evidence so here you go:



Supermicro X8SIL-F

It supports the Intel Core i3 with ECC. The spec sheet and documentation aren't entirely clear on this point so I asked Supermicro for confirmation. Their reply:


I wasn't entirely satisfied with this answer so I asked Intel too:




I'm buying this board with a Core i3 as part of my new ZFS build. Come take a look and tell me what you think of my choices.