Comment by techntoke | Hacker News Reader

Comment by techntoke | Hacker News Reader

Good for Linus. I'm honestly surprised that he doesn't try to get more involved in promoting more competition and openness of hardware vendors, but I do appreciate his general neutrality and style in the community that he has fostered. However, he could potentially create more positive influence within innovation if he took a more stern stance and really pushed back, but I'm guessing he has to walk a pretty fine line to politically operate at the level he does, or he would risk corporate backlash that has near infinite money to set the narrative.

I do wish though that he would take more of the Stallman approach, and advocate for more open-source activism via tech, especially when it comes to politics and governance. There is so much potential to really improve the environment, social justice, and create a society that prioritizes innovation over greed, but unfortunately it seems like it would take someone like Linus to really push the agenda in the position that he is currently in, rather than wait to see what happens after he is gone, because there will be a lot of disingenuous people that will try to take his place.

On the post, if Linus is referring to low-end Xeon and workstation non-Xeon lacking ECC, I think it's completely idiotic. Nearly all infrastructure should be baking in ECC as standard rather than some "option" to not have silent, unknowable, probabilistic corruption that is realistically realizable on a near-daily basis given the orders of magnitude of network, storage and computational volumes of today (and the future) by ever lower tiers of end-users and common examples of network infrastructure.

DEFCON 19: Bit-squatting: DNS Hijacking Without Exploitation (w speaker) https://youtu.be/aT7mnSstKGs

The sad thing is that I have seen signs of AMD starting to do the same. When I was shopping for a motherboard lately, I've begun seen motherboard manuals that state "ECC is only supported with PRO CPUs."

See http://asrock.pc.cdn.bitgravity.com/Manual/X570%20Phantom%20...

I think taht Picasso is actually an APU (CPU+graphics) and before Ryzen/Zen they never supported ECC. So, I think that ECC is for PRO APUs is an improvement.

I guess it depends on what "supported" means in the context of the mobo. I'm always afraid its going to mean that I cannot enable scrubbing, etc, if the cpu is not "supported"

> before Ryzen/Zen they never supported ECC

Incorrect; there were a bunch of AM3(+) boards which advertised ECC support back in the day. The IMC of AMD's desktop processors always supported ECC if I'm not mistaken.

AM3 is not for APUs, though. FM2 is.

As far as i know this is only true for APUs. Cpus without a gpu don't have this limitation. Also most mobo manufacturers don't seem to emphasise any ECC features as there are no RGB lights on any of the available DIMMs I assume.

you can retrofit the rgb don’t worry!

Key word “supported”. AMD's consumer chips have ECC enabled but it is not validated.

what does enabled but not validated mean?

Basically that you can't return the chip to AMD if ecc doesn't work.

ECC DRAM support is physically present in the chip, and will work if the motherboard supports it, but it's _up_ to the motherboard to support it.

Some Ryzen motherboards are marketed explicitly as having ECC DRAM support (e.g., ASRock Rack X470D4U, ASUS Pro WS X570-ACE).

Other Ryzen motherboards have ECC DRAM support, but they don't advertise it as a feature for one reason or another (most of ASRock's motherboard lineup, many mid-range ASUS motherboards, possibly others).

Still others completely lack ECC support (many low-end boards, as well as high-end gaming-focused boards).

> what does enabled but not validated mean?

Basically, it means that it's optional. As described above, ECC can work or not work depending on which specific motherboard you get, and it's up to the system integrator to choose a motherboard compatible with ECC if that's a desired feature.

That's as opposed to "validated" ECC support in, say, AMD's Threadripper platform. In that case, if a company builds and markets a motherboard as compatible with Threadripper, and it lacks ECC support, they can expect to receive a nasty letter from AMD's legal team.

> That's as opposed to "validated" ECC support in, say, AMD's Threadripper platform. In that case, if a company builds and markets a motherboard as compatible with Threadripper, and it lacks ECC support, they can expect to receive a nasty letter from AMD's legal team.

Are you sure about that? I'm only asking because the System76 Threadripper Thelio[0] doesn't support ECC (according to the response I received from their support people). Their response was actually that "Threadripper and our motherboard do not offer ECC" (TR obviously does support it though), but is it the case that they're actually contractually obligated to support ECC?

[0] - https://system76.com/cart/configure/thelio-major-r1

It's EPYC that has ECC. Threadripper is for enthusiasts, not the professional market.

Threadripper and many Ryzen chips support ECC as well, and the professional market can use either and still be professionals.

I'm running ECC memory on my R1700X... I'm fairly sure TR also has ECC memory. In fact, all of AMDs offerings except for APUs have ECC enabled, but AMD does not force motherboard manufacturers to implement it.

EPYC has registered memory. While ECC is (traditionally) more common in RDIMMs, it's also available in UDIMMs.

> I'm only asking because the System76 Threadripper Thelio[0] doesn't support ECC

The Thelio Major uses a Gigabyte X399 Designare EX motherboard, which has ECC DRAM support. System76 may not offer or support ECC DRAM as an option, but you can add it yourself if you're so inclined.

Okay, that's actually great to know. Thanks!

Same goes for memory and virtualization encryption.

They should be standard consumer features. SEM "sort of" is, but I believe it's not enabled by default on many BIOSes, and SEV is reserved to Epyc. In a time that even Windows 10 has Windows Sandbox and Edge App Guard as consumer-centric virtualization features, supporting virtualization encryption is starting to make more sense. And of course there are all the "pro" people that were already playing with VMs on their machines.

Granted, SEV seems kind of broken/insecure, but I'd still like to see an improvement version coming to consumer Ryzen within the next-generation or two. It coming to Zen 3 chips would probably be ideal, because I don't think AMD will be able to show yet another impressive increase in performance with them, as they will remain on a 7nm process, and Zen 3 itself is supposed to be more of an iteration to Zen 2 anyway. This way at least they can lure people with "more security features", as well as other features like AV1 hardware decoding/encoding support.

> low-end Xeon and workstation non-Xeon lacking ECC

To be fair the single socket, low core count Xeons are not that pricey unless you try to match clock speed with the consumer chips... But, priorities, right?

Intel's blocking of ECC features is entirely arbitrary and artificial, the dies themselves already support it, they just disable it for consumer chips.

Ah I see, that's a different thing entirely

I found the studies that this video (17:15) uses to establis a real world DRAM BER.

https://tezzaron.com/media/soft_errors_1_1_secure.pdf

https://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf

You’ll note that the papers were published in 2004 and 2009, respectively.

Here is a paper from 2015 that paints a more accurate picture of hardware used today.

https://www.cs.virginia.edu/~gurumurthi/papers/asplos15.pdf

Apparently these studies have strange ways to present data and do not give straight “BER per bit per second”, which I would think is the most useful metric. Without spending all day learning the jargon of this specific field, I think I can conclude, at a glance, that DDR4 has a lower BER than DDR3. The numbers matter, and I don’t know how serious of an issue it is currently. Without that knowledge its impossible to speak on the efficacy of more proliferated ECC in DRAM.

> On the post, if Linus is referring to low-end Xeon and workstation non-Xeon lacking ECC, I think it's completely idiotic.

I have said it before, I'll say it again, it is completely moronic that literally all storage and every bus in your computer uses FEC or at least uses checksums, except main memory and the memory bus.

OK, devil's advocate here. Intel wants to segment it to make money. Perfecty rational, right?

Also consumers want it that way as ECC needs extra bits and run a few percent slower. If gamers are willing to overclock their CPUs then they probably don't much care for slower memory. And $cost.

I agree with you, but others have different priorities.

(not an intel shill BTW)

> If gamers are willing to overclock their CPUs then they probably don't much care for slower memory. And $cost.

Then they can continue to buy and use non-ECC memory

That was my point.

Intel supporting ECC RAM would not preclude them from doing so

Coincidentally, a Xeon NUC with ECC just leaked; maybe Intel's strategy is changing. http://www.fanlesstech.com/2019/08/the-very-first-xeon-nuc.h...

Reply on news.ycombinator.com