![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
https://www.phoronix.com/scan.php?page=news_item&px=Linus-Torvalds-ECC
![Zarathustra[H]](https://cdn.hardforum.com/data/avatars/m/9/9298.jpg?1707758471){kind=avatar}
The only time I have found EEC guaranteed to work is on Xeon and EPYC platforms, outside there it's a crapshoot, and even then I have had AMD bios updates break that compatibility.
The 'best' way to test ECC is to run with your ram at intentionally too tight of timings, or too low of voltage, so that it will have errors. And confirm that reporting is working. I saw in the mailing list thread there is a fault injection tool for AMD processors, that could work, too; if so, it would be a lot less work.
The only way I have really found to "test" it is to 1 check the bios for an ECC flag, no flag no bit support, then 2 boot up a copy of Memtest 86+ and check the EEC flag there, then lastly use a live boot of Ubuntu and do the eec_check.c test there. But that is a lot of steps and a by the time you can do those you are already out of pocket, it is a most annoying process and honestly I've just come to the conclusion that if I have something that I need ECC support for I will just justify the added cost of ordering from Dell and ensuring that it is part of the initial configuration, sadly that means no Threadrippers, only Xeons, and EPYC.
Many boards (Asus at least) on the functionality page now say they support ecc ram ("Supports ecc ram in non-ecc mode" or something similar) or support ecc completely. I believe Linux has functionality to inject errors which shoudl be caught & logged if it is working.
Yeah, Ubuntu live USB key with eec_check.c compiled and ready to go is in my tool kit for when I am doing my dry test of servers before deploying them. But sadly the flags for "Supports ecc ram in non ecc-mode" and what not is at the board makers discretion and their not always up to date on that either on the site so you have to deep dive the documentation but you should do that beforehand anyways when making a purchase, so, really it's just one more step to add to the server/workstation building process.
This doesn't get tested because effectively no one looking at HEDT systems cares.
It's more the added time it takes to verify the ECC bit that adds to the timing as technically it is moving more content, but generally for applications that you would want the ECC for the difference in timings for that memory is not going to have any real change on the speed at which it runs because the other aspects of the system are far slower and in those cases, it is the amount of memory that is important not the speeds it runs at for the most part.
Somebody has to do it. Damn kids.
Sometimes it takes someone with a higher profile and larger reach than just a lot of enthusiasts complaining about it. Maybe it will finally be addressed by manufacturers.
I doubt he is anyone important enough to stir the pot. He just seems like a cranky fuck.
Yea that's all I see from him. He might have pull in the linux community but doubt it for any hardware manufacturer.
ECC doesn't prevent rowhammer, but it does mitigate it. All single bitflips are reported, and if nothing else, the interrupts for reporting will slow down further attempts. All (most?) double bit flips are reported uncorrectable and are likely to halt the machine (depends on your os and the modified page though, some OSes will determine where the bad memory was mapped to, and kill affected processes rather than the whole thing); even if you don't put correctable errors into monitoring, uncorrectable errors should make it. Only the tripple or more flips have a chance at being undetected; those aren't impossible with rowhammer, but they're less likely (unless the technique has been significantly refined since I last looked), and you'd leave a big trail behind you. For the types of servers I've run, that's been good enough for my piece of mind; but then, those servers weren't expected to have adversarial code running on them.
From the article:
He is totally correct, and that is exactly what Intel has done over the last 20+ years with their marketing nonsense.
DDR5 ECC has 72 lanes and non-ECC has 64. Pretty easy to disable lanes in a memory controller. The DDR5 spec actually defines BOTH.
Apparently there is a nuance between ECC capability inside the ram (that make what goes to the ram be and stay valid) with total ECC, if the issue occur before the data reach the ram, with DDR5 build in ECC issue can still arise. Do not quote me on this, that something I just read for the first time like yesterday, could be repeating wrong.
I am not sure any of Intel current issues or competition has to do with lack of ECC support on non server and other chips, it is not like some of their biggest competitor like AMD are not doing the exact same things than them on that front. Maybe it did participate into loosing Apple has a client to have something called MacBook pro not supporting ECC being strange, but maybe not.
no read the spec
I’ve got 2x16 3200 Kingston in my FreeNAS box. Happy so far.
Do you mean bits instead of lanes?
haha, it's just been one of those days
