Extra funny when you notice that certain Xeon lines are actually i7 with different branding and ECC left enabled.
The problems with ECC on AMD comes from consumer vendors not putting the time into testing, and possibly not even connecting the ECC lines (remember, ECC requires putting additional traces between memory controller and memory slots). Then you have to deal with whatever customisation the vendor of the motherboard did to firmware - their changes might have resulted in effective disabling of ECC.
With Intel, you either have the same game as above (with the non-Xeon ECC-capable parts), or pay through the nose for comparable performance "workstation/enterprise" gear, as ECC support being used for market segmentation by intel is pretty much an open secret.
The only advantage of Intel Xeon at this point is RDIMM/LR-DIMM support on their Xeon-W platform. AMD supports that only on Epyc and Threadripper Pro.
And that gen of CPUS had low power T-series chips rated at 65w where today it's 35w. The power drop is part of why I'm happy with my SFF setup as the thermals are quite good on 14nm locked CPUs like my 7700.
If you want verified ECC support, you need to buy the workstation chips and motherboards: Threadripper Pro or EPYCs.
I went through the effort of using qvl memory, but actually testing ECC is a bit more difficult. While ECC is supported & active, memory errors are sadly not reported to the OS. I remember seeing a forum post somewhere of somebody overclocking/undervolting the ram to force errors, but I can't seem to find it right now. There's a fine line between stable, stable with recovered errors, and unstable.
So on Linux, ECC is fully supported, even with Ryzen.
https://www.servethehome.com/asrock-rack-x470d4u-review-amd-...
With Ryzen 3xxx, I have used ASUS Pro WS X570-ACE ($315), which is sold as a workstation board, so you definitely should expect ECC to work without problems, and also the Mini-ITX MB ASRock X570 Phantom Gaming-ITX/TB3 ($230), which also worked OK.
I expect that the other ASRock MB's (most of them or maybe all of them specify the support of ECC) also work OK with ECC modules.
The ASrock Rack server board should also not have any problems with ECC. IIRC that server board supports only up to DDR4-2933, but until now faster unbuffered ECC memory modules were not sold anywhere, so that is not a disadvantage.
Edit: I have looked again at the ASRock site and they have updated the memory support specification. If you use only 2 UDIMM modules (i.e. up to 64 GB total), then you can use up to DDR4-3200 (which I have never seen offered anywhere until now; 2666 is easy to find, 2933 is also supported by Intel since March, so it should become available soon).
https://forums.freebsd.org/threads/how-to-find-out-if-ecc-is...
Example: https://www.asus.com/no/Motherboards/Pro-WS-X570-ACE/HelpDes...
In that price range, AMD markets Threadripper and Epyc, both with proper ECC support.
ECC support in Ryzen systems is up to the motherboard manufacturer, and some manufacturers advertise support very clearly. E.g., at least a couple years ago, ASRock explicitly supported ECC in all their Ryzen motherboards.
Most people wanting ECC just for the warm fuzzy enthusiast feeling would prefer Ryzen with good MB that supports ECC. Intel makes more sense at the high-end many-core Xeons, due to supporting huge memory with much higher throughput (LGA3647). But that segment is bonkers-expensive.
That's not a real need, of course, it's just some kind of whim, but if I can pay for it, why not. Just like those crazy overclocker dudes pay for their whims.
For example I am using an ASUS Pro WS X570-ACE, which is a reasonably priced workstation board ($300) with a Ryzen 7 3700X and ECC memory.
ECC worked OK, without any problems. I have also used a couple of ASRock MB's and ECC also worked OK on them.
I would much prefer more guarantees from AMD, but rather than buying a slow Intel CPU I prefer a little risk with AMD.
It's a shame they made the TR platform much more expensive in the last generation.
You want ECC in your desktop if you cannot afford your data to become (silently) corrupted. A single bit-flip in a JPEG image can totally ruin it. And you won't notice without opening it, because the thumbnail is unaffected. When you finally notice, the corruption has possibly spread to backups already.
For servers that is especially important, because data will reside cached in memory for days or even weeks. Also ECC is often the last line of defense against Rowhammer.
FIT (failures in time, or failures per billion hours) are about 20-30 per DRAM (18 per DIMM in the study) at a fault level, which may not rise to an error condition. ECC corrects many faults, if present, which don't become errors.
So expect a (4GB in this study) DIMM to have a fault once per 200 years on average. Of course, this is server-class hardware running ideal conditions.
This is, notably, in stark contrast to Google's results (https://research.google.com/pubs/archive/35162.pdf&) of about 20,000-70,000 FIT per Mbit, but closer reading suggests that there were a fairly large number of high-fault DIMMs affecting the mean and Google historically bought the cheapest hardware available. Even at this fault rate an average DIMM wouldn't fail in any given month, for example.
Personal gaming, browsing and light document work PCs do not need ECC. Video/photo editing/development PCs might be on the threshold for not wanting to produce or store corrupted work.
Multiply the risk out for any organization with many people doing the same kind of work where corruption on a single workstation could cause annoying trouble for everyone else.
tl;dr: one bit error in 4GB every 72 hours
https://nakedsecurity.sophos.com/2011/08/10/bh-2011-bit-squa...
It would be interesting to repeat this experiment today.
1. https://web.archive.org/web/20010612184424/http://www.boeing...
Here is an example: ASUS Pro WS X570-ACE