The “E” generations of Xeons are - to generalize broadly - all very hot and high-power even under idle. The motherboards are generally more expensive than the CPUs and the only cheap option are usually OEM workstation boards that tend to be very finicky about very specific things, like case intrusion.
Ryzen ~does~ have unofficial support for ECC on AM4 boards, and official support for Ryzen Pro, there are a lot of the “G” CPUs available and often lower prices than standard Ryzen too. Ryzen does have a decently higher idle wattage than standard Intel but it’s nowhere near those Xeon levels.
It really depends on how much performance and RAM you need.
Unfortunately there are not many new cheap boards from Supermicro but I like the A2SDI-8C-HLN4F-B and X11SSM-F mobo.
… so at least it looks like ECC is supported (SECDED here I assume means Single Error Correction, Dual Error Detection). Is it actually working though, as in does it detect (and correct) errors and are they reported to the kernel? I haven’t seen any errors, so I can’t tell for sure.
I don’t think Xeon E3 are as power-hungry as you imagine - those would be the E5 or E7 series. The E3 series is more or less the same as the desktop parts except with ECC support. Less than 50 watts idle would be quite normal, but this depends on the other hardware in the system.
I recently put an i3-7100 into a backup server myself, with unbuffered ECC DDR4-2400. Same generation (Kaby Lake) as the Xeon E3 v6, just with 2 cores instead of 4, which is enough for me. It’s a decent and low power platform with official ECC support if you don’t need a lot of compute power or the latest PCIe support.
To my understanding Ryzen supports only unbuffered/unregistered ECC which is different from buffered/registered ECC. I am basing this info on stuff I have read on all types of forums and I might be wrong here.
The type I would like to have is buffered/registered ECC. The type which corrects errors and increases stability.
I haven’t used any such platforms myself, but if I was looking for cost-effective RDIMM platforms, I’d consider older EPYC like Naples or Rome, or maybe Xeon Scalabe Skylake. They aren’t known for being low-power though. The Xeon D or Atom C series might be an option for low power RDIMM support, but I expect they’ll be slower, especially the Atom C series.
Out of curiosity, why do you consider RDIMM a requirement? Unbuffered DIMMs also have 1-bit error correction and 2-bit error detection, which should have the same effect on stability as RDIMM.
If they’re both EC4, yes. If you want chipkill instead of SECDED that takes an EC8 RDIMM, but most DDR5 RDIMMs I’ve come across are EC4. Bot seems also have some confusion of non-ECC with EC4 plus maybe overlooking DDR5’s on-die EC2 scrubbing abilities and read CRC closure. They’re not the same but as a result non-ECC DDR5’s arguably more robust than EC4 DDR4.
For clock distribution it’d be CUDIMM to RDIMM equivalency. If CUDIMMs happen, anyways. At one DIMM per channel DDR5-6000+ non-ECC UDIMMs are doing fine, though, so I share your curiosity as to what motivates the clock buffer requirement.
I know various ASRock AM4 and AM5 desktop boards have been tested with fault injection and found to report, the issue seems more to have been AMD broke ECC in an AGESA release shortly after Zen 4 launch. From what I’ve been able to make out, that got fixed fairly quickly and seems to have been stable since.
Personally, I’m pretty comfortable assuming that if ASRock indicates ECC UDIMM support SECDED is included. Trust levels vary on this, though, which IMO is understandable.
Not necessarily. Prior to DDR5, registered ECC memory and unregistered ECC memory had the same ECC capabilities.
Also registered ECC memory is not fully buffered, they only bother to put buffers on the command and address lines and not any of the data lines; all of the data lines on RDIMMs are completely unbuffered. An LRDIMM would get you the fully buffered memory setup but can be problematic to cool.
Full buffering became a thing in DDR2, IIRC, to support more than four DIMMs per channel as quad rank wasn’t added until DDR3. This continues with LRDIMMs for high memory setups. I believe with RDIMMs the address and command buffering’s to similarly enable quad and oct-rank DIMMs. A disadvantage is buffering (typically) adds a clock of latency.
Buffering allows DIMMs to provide supporting signal drive power, offloading the CPU, and improves signal integrity at higher rank counts by terminating and regenerating what would otherwise be a fairly complex net. This is part of why UDIMM overclockability drops more rapidly than RDIMMs’ as more ranks are added to a channel.
At the moment it goes something like this for DDR5. This with just some quick checking of what’s currently available so if you look around probably the numbers can be moved somewhat.
This begs the question: why is RDIMMs used in today’s multi-channel DDR5 systems which only support 1 DIMM per channel anyway? (E.g. most EPYC SP5/6 motherboards.) To support longer traces to the slots furthest from the CPU?
Some increase in allowable CPU to DIMM socket distance seems plausible to me as well. Whether it’s of functional significance I’m unsure, but with like a 12 DIMM socket at DDR5-5600 it seems plausible.