Background about my question goes like this: I'm helping a friend with a build which has the budget and use case to go for a true Workstation. My idea was to recommend him an Intel Xeon E5-1620v4, a Supermicro X10SRA (I also was a bit interesed in the Supermicro X10SRA-F due to the integrated VGA more than IPMI itself, as it should be good enough for a Linux console host if doing VGA Passthrough, otherwise the host would be headless), and 4 * 8 GiB of ECC RAM (Still didn't decided if UDIMM or RDIMM would be better, and what brand and model). However, since the X10SRA is a rather dull first generation Haswell-E Motherboard and Supermicro doesn't have anything newer aimed for Workstations than it, I decided to look for other manufacturers that released "X99 Refresh" Motherboards for Broadwell-E, and after searching a bit falled in love with the AsRock X99 Taichi due to its simple PCIe topology and excellent features for the price.
This is when I hitted a rather important issue: While supposedly I can use the Xeon and either DDR4 UDIMM ECC or RDIMM ECC with it, I recalled THIS Thread, which as far that I could google, is about something extremely obscure, and didn't saw anyone else talking about that.
Basically, it seems to be quite hard to know if ECC is enabled and working as intended or not, as there is conflicting info between what is set in the Firmware, what SMBIOS reports, and what a tool like MemTest86+ reports. In order to figure out if ECC is working or not, someone did it low level style with a small Linux application that retrieves the reelevant values about ECC status from the Processor itself.
According to the HardForum Thread from info coming straight from the Processor Data Sheets, there can be FOUR different ECC status (Off, On, and two different partial On). The application is supposed to tell you what of these four statuses the Memory Channel is on.
At least the way to access that info applies since consumer Sandy Bridge to Haswell, Skylake seems to have changed it so it is no longer valid, and I have no idea about Broadwell, Haswell-E/Broadwell-E at all.
In around 4 years, there has been very little reports about ECC working or not. ALL the people that had ECC reported as "On" were using proper Workstation/Server setups: Processors with ECC Support (Pentiums, Core i3 or Xeons), a C Series Chipset, and ECC RAM. Point is, I recall hearing somewhere else that you NEED a Q or C Series Chipset to use ECC at all (It should POST and work with the ECC RAM, but ECC should go unused). Yet, many X99 Motherboards claim to be able to use ECC - but I'm not sure if they can actually use it, or merely POST with it.
Because enthusiasts forums are not the sort of place where I'm expecting to see people with ECC RAM, I decided to give a try to ask about this matter here. I would like to know if someone has the in-depth knowledge about this to explain what is going on, or to try to get a few guinea pigs with systems as the one that I'm intending to build (Xeon E5, X99 Chipset instead of C612, and ECC RAM), or consumer variants (Haswell Xeon E3, H87/Z87, ECC UDIMM RAM) that can test the application to give real proof about the matter.
This would give me peace of mind that the Xeon E5, X99 and ECC UDIMM/RDIMM RAM I recommended will work as intended, as otherwise I should keep looking for a viable C612 Motherboard that can compete with the AsRock X99 Taichi, or just go with standard UDIMM non-ECC RAM. But that would be boring, and too close to the typical enthusiasts systems that I like to avoid...
This is when I hitted a rather important issue: While supposedly I can use the Xeon and either DDR4 UDIMM ECC or RDIMM ECC with it, I recalled THIS Thread, which as far that I could google, is about something extremely obscure, and didn't saw anyone else talking about that.
Basically, it seems to be quite hard to know if ECC is enabled and working as intended or not, as there is conflicting info between what is set in the Firmware, what SMBIOS reports, and what a tool like MemTest86+ reports. In order to figure out if ECC is working or not, someone did it low level style with a small Linux application that retrieves the reelevant values about ECC status from the Processor itself.
According to the HardForum Thread from info coming straight from the Processor Data Sheets, there can be FOUR different ECC status (Off, On, and two different partial On). The application is supposed to tell you what of these four statuses the Memory Channel is on.
At least the way to access that info applies since consumer Sandy Bridge to Haswell, Skylake seems to have changed it so it is no longer valid, and I have no idea about Broadwell, Haswell-E/Broadwell-E at all.
In around 4 years, there has been very little reports about ECC working or not. ALL the people that had ECC reported as "On" were using proper Workstation/Server setups: Processors with ECC Support (Pentiums, Core i3 or Xeons), a C Series Chipset, and ECC RAM. Point is, I recall hearing somewhere else that you NEED a Q or C Series Chipset to use ECC at all (It should POST and work with the ECC RAM, but ECC should go unused). Yet, many X99 Motherboards claim to be able to use ECC - but I'm not sure if they can actually use it, or merely POST with it.
Because enthusiasts forums are not the sort of place where I'm expecting to see people with ECC RAM, I decided to give a try to ask about this matter here. I would like to know if someone has the in-depth knowledge about this to explain what is going on, or to try to get a few guinea pigs with systems as the one that I'm intending to build (Xeon E5, X99 Chipset instead of C612, and ECC RAM), or consumer variants (Haswell Xeon E3, H87/Z87, ECC UDIMM RAM) that can test the application to give real proof about the matter.
This would give me peace of mind that the Xeon E5, X99 and ECC UDIMM/RDIMM RAM I recommended will work as intended, as otherwise I should keep looking for a viable C612 Motherboard that can compete with the AsRock X99 Taichi, or just go with standard UDIMM non-ECC RAM. But that would be boring, and too close to the typical enthusiasts systems that I like to avoid...
