News AMD confirms Ryzen 8000G APUs don't support ECC RAM, despite initial claims

[bit_user]

I don't anyone is thinking about the idiocy that we have error correction in nearly ALL other PC subsystems,

Not error correction, but rather error-checking. In the cases I've looked into, there aren't nearly enough check/parity bits for error-correction.

Even the filesystems are getting error correction with ZFS and ReFS.

Again, if you just mean error-detection, BTRFS also has checksums.

And I think all of the current SSD products have error correction built in = making it cost parity as the market expects it to just be there.

It's there because NAND flash is vastly less reliable than DRAM. It's also there because it facilitates smaller cells & more bits per cell. So, having it is a net win. I guess DDR5's on-die ECC is there by the same rationale.

I have seen many market shifts that learned to adapt and absorb a change to keep the features up and cost down.

I think in-band ECC is the best chance for DDR to do this.

I guess I sort of wonder why we're so resistant to link parity/ECC being computed on-the-fly, now that the DDR5 dies have ECC on-die. If they would just expose error stats for that on-die ECC and maybe increase the ratio a little bit, then you could tell when a DIMM is becoming unreliable and do preemptive maintenance. IMO, that would probably be enough for most of us. If you needed further reliability, then doing in-band ECC on top of those features should be enough, even for servers. The really high-end folks can do memory mirroring, as I believe they already do.

 

[bit_user]

If there are already markets using ECC and it is having no drastic cost impediment, why couldn't the PC world do the same?

You're looking at the SoC cost and not the DRAM cost - or, not for a substantial amount of DRAM, if so.

The PC industry has the user conned into believing that there would be a drastic cost hurdle if ECC was across the board,

Nah, they've just mastered the art of "good enough". As long as conventional DIMMs are reliable enough, they want to avoid the overhead of those extra DRAM chips. Then, because it's an uncommon feature, Intel and AMD + their board partners can get away with charging extra for it - but that part is almost pure profit. For OEMs, the DRAM is a real cost increase.

 

[abufrejoval]

You've gotten somewhat off the track, I'd say.

ECC or not as part of the system design is one thing, the use of ECC where it is an option part of deployment design: both are valid insertion points, but both won't apply to all use cases.

I believe, you're mostly arguing use cases, which I'd consider a separate debate.

Here the main discussion was about how AMD is changing a rather essential assertion they made at the launch of Zen: no artificial culling of features which come included in the hardware as part of the system design.

And now they are breaking that assertion.

That deserves very lively customer feedback.

I personally can't think of any reason to encourage them to maintain or widen the scope of feature culling.

If you have any, please argue that point.

And for a while I've been trying to dig into the actual cause of the feature cull, if it existed.

And there I've been led to believe that the ability to support EEC depends on the choice of interposer and package format for the APU die: there are (at least) two BGA variants, of which one simply won't have the traces for ECC support, while the bigger BGA and the AM4/5 sockets have ECC trace/pin support available, which then obviously needs to continue on the mainboard etc. to actually work, if matching RAM is inserted.

Obviously the die needs to be told in which form factor it's deployed, and just as obviously, it's one of the first things they messed up with this G-series: the dies weren't told they're not running in a laptop and tried throttling for burn protection.

So that's the insertion point where they might also tell the die if ECC can be supported or not.

And yes, having inline ECC available as yet another choice at the point of deployment, would be a welcome feature that I'd even pay a modest extra for--if the mess of managing that feature as a SKU wasn't so big that they should just include it for free.

 

[bit_user]

Here the main discussion was about how AMD is changing a rather essential assertion they made at the launch of Zen: no artificial culling of features which come included in the hardware as part of the system design.

And now they are breaking that assertion.

No, as we've repeatedly said, their no-ECC policy for non-Pro APUs is not new! What the article is about is that they apparently said they would reverse course on that, with the 8000G, and now they've decided to re-reverse themselves and stick with their long-standing policy.

As for blanket statements they supposedly made about Ryzen, can you dig up a source on that? I'm curious about the precise language, because they've allowed ECC to be used on most non-APU desktop chips. So, maybe they believe that's all the original statement wast meant to cover.

it's one of the first things they messed up with this G-series: the dies weren't told they're not running in a laptop and tried throttling for burn protection.

That's allegedly a BIOS bug, it seems.

https://www.anandtech.com/show/2125...000g-apu-stapm-issue-sustained-loads-affected
​

I think it's not relevant to ECC and not helpful to conflate these issues.