My experience:
It confirms this:
You will simply not know if something is wrong until it’s too late.
And don’t think of ECC only as a protection against cosmic rays, failing memory modules are the higher risk in my opinion.
I went with last gen ryzen pro and ECC DDR4.
Does unbuffered ECC memory still help minimize the risk of such an issue or is it a case where Registered fully buffered ECC is what you would want for protecting against something like that.
In my understanding the module will not be able to correct these problems, but it will report them.
You might get some corruption, but at least you are able to configure alerts and know exactly when the module started failing.
80 bits for EC8 on 2x32 bit subchannels. EC4’s 72 bits total for 1x64 or 2x32.
Package count varies with the config. With an x16 24 Gb like MT60B1536M16RV-56B:B EC8’d potentially be one more package. Won’t matter much to cost though since it’s mostly die area.
(As an aside, config probably also influences achievable clocks and timings.)
exactly, which makes it strange that the DDR5 ECC UDIMMs have either 2 or 4 extra DRAM packages (over non-ECC) depending on if they are single or double ranked assuming they are x8 organized. That’s 80 bits of DRAM width on the UDIMM, even if the CPU only uses up 72 bits.
But did you choose Ryzen 7400F without the iGPU on purpose or not? People online say that the iGPU does have an encoder. NB: Intel’s encoder is still one of the best.
Have you considered an iGPU-enabled Ryzen or ECC-enabled Intel chips (which, btw, seem to be the exact same silicon but different features enabled). FWIW TPU lists that Intel 13400 has the same iGPU as 11400. Ultimately, you’ll want to go by the respective encoder/decoder capabilities to reach a conclusion what kind of CPU/GPU you want: Intel Quick Sync Video - Wikipedia
What about older platforms with DDR4 ECC to lower the cost? Additionally, you’d want to consider increased dGPU power consumption too.
I was one of them. And luckily it had only and persistently hit Firefox. A single bit that has gone bad after years of use on my desktop system.
Personally I’m going with non-ECC DDR4 but only because I’ve already had the motherboard. I understand this is a ‘temporary’ solution and eventually I’ll want to move to ECC for my NAS. I’m not going to use ZFS out of fear of cascading failure. It’s a gamble:
Isn’t this because of the two sub-channels on DDR5? I.e. you cannot share dies between the channels – one channel might be waiting to stabilize while the other is getting a new address written, for example – so you need 5 full x8 chips per channel and rank, even if that means you throw away 4 bits per channel.
I don’t think there’s anything preventing 2 x16 + x4 or 4 x8 + x4 per subchannel. In principle you could also have an x4/x4 bifurcatable x8 but, so far as I know, nobody makes that.
In practice that’s probably prevented by cost and complexity. An additional part to handle in the SMT line and to match timings and terminations to? Nah. Most likely it’s both easier and cheaper to just throw those bits away.
Maybe I should have written “so given that you use x8 chips, you need 5 of them per subchannel and rank”.
Is unavoidable given bus ECC requires extra bits and available DRAM organizations. 2 x16 + x4’s simpler than 4 x8 and if eight check bits were required per subchannel I’d expect to see more EC8 RDIMMs and fewer EC4s.
An additional package is unavoidable, yes. An additional part no (an additional line in the BOM), not so.
My guess as to why there are two extra x8 packages (for 80 bits in total) on (single-rank) DDR5 EUDIMMs rather than one, as twin_savage thought strange in the post I quoted, is that
Why else would they (universally?) use only one part number and throw bits away rather than mix and match part numbers to get exactly the 4 check bits per sub-channel required on EUDIMMs?
And again, using multiple different part numbers would complicate timing and termination issues even further, and we all know it’s already a mess with DDR5.
hmmm… you might be on to something there.
*puts on tin foil hat:
I swear this has come up before on this forum and I looked into the consumer socket pinouts and came to the conclusion AM5 does not even have the extra pins to support EC8, neither does LGA1851, however LGA1700 did have the pins to support EC8 so maybe it was some kind of unimplemented feature and the memory manufactures just made all DDR5 ECC UDIMMs “EC8” to accommodate? It wouldn’t be the first time Intel went ahead of JEDEC and dictated memory standards.
No. CB[7:4]_A and _B are only present on RDIMMs.
Speaking as someone who did DDR R&D for a living for a while, this is incorrect. If you wanted to point out it’d have been better to stick with 1SPC for DDR5 DIMMs and use CAMM2 for higher capacities I’d agree but that’s not what the industry’s rolled out. Which is arguably on JEDEC as they didn’t standardize CAMM2 until December 2023. But AMD and Intel are both JEDEC member companies, so that should tell you something about how important they think 2DPC is.
You seem to be assuming x4, x8, and x16 would put different IO blocks under the data bumps but it’s more likely the same block on the same process across all the dies. Other arrangements would impose additional NRE and I’m not seeing a reason to go there.
Of negligible importance compared to the die area cost. Yeah, the product photos for KSM56E46BD8KM-48HM, MTC20C2085S1EC56BR, and such show 10 balanced packages. But I wouldn’t take that to be the actual layout without sticks in hand to confirm and, since the packages appear unlabeled, it might require stripping them down to check whether the dies are identical. MT60B4G4RZ-56B:D and MT60B4G8RZ-56B:D use the same package, for example.
Strongest argument I see for a 5 x8 appearance is yield recovery, which’d be pretty much the opposite of throwing away unused bits.
No, that wasn’t my point at all.
That was my assumption, yes. Or at least I assumed that it would be cumbersome to source different parts while assuring they match. (Maybe not so much of an issue for manufacturers who are “vertically integrated” and make both the packages and the DIMMs, but I can imagine 3rd party DIMM manufacturers having a difficult time with this.)
But I’ve never been involved with large-scale manufacturing like this, so maybe the additional BOM line and the supply issues aren’t a big deal in the grand scheme of things. I’ll take your word for it! 
Yield recovery is an interesting aspect of it. But that would still require keeping track of an additional part number.
I read somewhere, a long time ago, about a McDonald’s (I think it was) factory for fries that used camera image recognition to detect bad parts of the newly shredded potato strips (before cooking). Those strips were blown off the normal conveyor belt using compressed air onto another belt. That belt was then further inspected and little knives cut out the bad parts of the strips before they were returned to the main belt. (And this was before the turn of the millennium so rather high-tech for the time!)
If it was worth going to those lengths with potatoes, it’s probably worth it with RAM dies. 
Edit: And you’re right, I haven’t inspected any DDR5 ECC UDIMMs to check that the parts are all the same. It was a carry-over assumption based on DDR4 (where they naturally of course are all the same). 
As long as I am the one paying, I am fine with ECC.
Go with the Intel system. Remember to always backup your data. You’ll be happier and your data is about as safe.
It is true that RDIMMs are the only ones that have CB[7:4]_A and _B defined in the spec; but I see 6 (pins 7, 75/76, 143/144, 213/214, 219/220 and 225/226) ideal and 3 (pins 149, 152 and 288) okay-ish RFU pins on DDR5 UDIMMs that could be used to carry the 8 extra CB signals. It would be really interesting to see how these pins are routed on actual DIMMs or if the extra pins on LGA1700 route to any of these DIMM pins (the latter could be done non-destructively).
Now that I’m thinking about it more, perhaps the reason the ECC UDIMMs have the “extra” packages on them is because there is no way for the right CAs to be active to dump the correct parity DQs on a single chip without a register chip doing the address translation for the subchannels like the 9/18/36 package count EC4 RDIMMs can do.
I have, and at least on the ECC UDIMM Nemixs I have, all 20 packages are the same.
Is address bus ECCed also?
If not, there is possible that you read the wrong address and you don’t know.
DDR4 UDIMM/RDIMM support command/address (CA) parity to detect any bitflip in the command or address pins. On a parity error the command will fail, it cannot be corrected like with ECC, so would need to be retried.
DDR5 RDIMM supports CA parity per channel.
DDR5 UDIMMs are missing the PAR_A / PAR_B pins required for CA parity, AFAIK.
Here raises a very interesting question. Hope owners of AM4 Ryzen motherboards with ECC memory could chip in.
In your AM4 BIOS, do you see command/address parity settings ?
If not, do you know if they’re enabled by default when you insert ECC DIMMs ?
If not, are you even sure your motherboards have two extra wires for C/A parity bit and ALERT# signals wired for each channel ?