Hacker News Reader

Comment by orbz | Hacker News Reader

The cost of increased performance and efficiency is unfortunately met with an increase in overall fragility of the system. As gate sizes shrink down they’re more susceptible to fluctuations in voltage, temperature and electromagnetic induction.

So yes, you could have a very robust system, but you’d have to pay more for less RAM, which market forces have chosen against.

View on HN

Fundamentally irrational market forces, we might add. No person compares spec sheets and chooses the chip with a 10% efficiency advantage but with a rowhammer style vulnerability instead of the 10% less efficient chip without a rowhammer style vulnerability. At least I've never seen "is susceptible to rowhammer" in a spec sheet. So as consumers, we don't really have the choice to select the more expensive or less efficient but more robust chip. Hell, ECC isn't even an option for most classes of CPU.

Why not? There are CPUs being designed that do floating point math “wrong” but faster…

I’m sure many people would use RAM that’s cheaper and faster but row hammer vulnerable. Just as many people drive cars with engines that will break if driven at redline for long periods of time.

It’s not like row hammer is a realistic use case. No algorithm depends on row hammer access patterns. Just like people don’t buy cars to bounce off the rev limiter.

"Why not" what? Why we don't get the option to buy rowhammer-resistent RAM? I don't know, ask manufacturers and resellers I suppose? I don't make the spec sheets.

If you run a server farm, you absolutely know these things. And you are using ECC based RAM.

Most of us don't run server farms.

Most of us don’t care about rowhammer then either.

You have the option, you just choose not to pay for ECC ram.

That is fundamentally different. Floating point computation not nearly as always needs to be done to the last digit of precision. For a lot of application 10^-8 is more than enough, for some even less digits might be enough. But fast calculation might be a lot more important if you're in a real time scenario or if you're doing HPC.

On the other hand, is not only row hammer attacks that cause bit flips, random bit flips happens, cosmic ray or decline of radioactive particles might cause one. And there is _no way_ to know if one happened on non ECC RAM (I know, ECC only reduces the probability of not noticing it, but it reduces that probability), and given that there is not way to respond.

If one random bit flip happens, best case nothing happens. If you are unlucky, maybe your system will crash. If you are really unlucky your data might end up corrupted and the OS might not even be able to detect it. Or maybe you were running a 100 hours calculation, and it might go wrong in the first minutes because of a bit flip and your simulation is ruined.

Floating point operations is about precision, witch can be studied and decided based on the needs of the application, bit flips are about data corruption.

I'm guessing more crashes occur because of bugs in software or RAM / CPUs that are already damaged than row hammering.

No they are fundamentally rational. If some memory ended up making computers crash a lot and corrupt data because it regularly was flipping bits this would eventually create a bad reputation and it would be avoided over time. Rowhammer uses fundamentally unnatural access patterns to flip bits which never occur outside of running the rowhammer test so the market places a rounds-to-zero value on mitigation. And despite that DDR5 is still much less vulnerable (although it’s unclear if that will change) to rowhammer despite higher clocks and densities.

How can it be fundamentally rational when you're making choices without critical pieces of information?

And why are you discussing crashes? Rowhammer is usually considered a security vulnerability, not a general reliability issue, right?

I'm confused by what you're trying to say.

ECC deniers are quite difficult to understand. Once one has experienced an unreliable system with a few bad DRAM bits that caused data corruption, the 20% premium for ECC is well worth it. An hour of my time being wasted on debugging a wonky system more than pays for that.

Because economic rationality doesn’t require perfect information. And I’ve yet to see any practical rowhammer implementation in the wild which could target the browser.

"Economic rationality doesn't require perfect information" may or may not be true in the general case. But if I want a system that's not vulnerable to rowhammer, and I'm buying new RAM sticks, the fact that I can't know whether a candidate RAM stick is vulnerable to rowhammer or not means I can't make rational choices, no?

memtest86 absolutely can find rowhammer failures, but beyond that even if you specifically don’t know how to do that, others do and publish their findings and if some ram was really worse than others in a meaningful way here that information will be available as a noisy signal for ram purchase choices.

Most people don't do that much critical stuff on their local computer, as all their critical data is stored by Google or Microsoft and they just transiently interact with it via web applications. What they do do on local computers that could be at all complicated is play games.

The goal of a computer for the majority of users (aka, not us developers) is thereby to be as cheap as possible while being just stable enough to not fail so often as to be too annoying, while preferably being as fast as possible under highly constrained conditions to play games at high quality.

It is unfortunate that chip making is so complex and capital intensive that a disruptor company would struggle to move in and take advantage of this opportunity. To do so competitively would require deep pockets and deep expertise, both not well-aligned with disruption. But you’ve pretty clearly outlined a product feature that is not discoverable in the market today, which means that a disruptor who could get off the ground ought be able to differentiate by making this discoverable. Doing so would quickly lead to price discovery and if the margin were there, the rest of the dram producers should fall in line fairly quickly to provide this information for their products as it suddenly becomes an axis they can (must) compete on. At least in a perfectly spherical frictionless market anyway..

Edit: downvotes? Really?

What about error detection and correction? Can it be used with the more fragile kinds of Ram?

Yes, but it costs more (in $$ and performance)

Is there still a whacking great price premium between ECC and non-ECC memory for desktop, but not server, motherboards? If so then that suggests that there's more going on here than a simple expression of consumer choice.

>Is there still a whacking great price premium between ECC and non-ECC memory for desktop, but not server, motherboards?

Yes for both.

Price: On pcpartpicker a stick of 16GB DDR4-3200 memory without ECC costs $28.99[2], but the ECC version costs $52.99[1]. Even factoring in that ECC ram comes with an extra chip, it's still 62% more.

Performance: using the same links above, we see that ECC ram tops out at 3200 MT/s, whereas for non-ECC you can get 4000+ MT/s. The brand selection is also better, which is critical if you want to get high performance memory chips like samsung b-die or micron E die.

[1] https://pcpartpicker.com/products/memory/#b=ddr4&E=1&sort=pr...

[2] https://pcpartpicker.com/products/memory/#b=ddr4&E=0&sort=pr...

> Performance: using the same links above, we see that ECC ram tops out at 3200 MT/s, whereas for non-ECC you can get 4000+ MT/s. The brand selection is also better, which is critical if you want to get high performance memory chips like samsung b-die or micron E die.

Notable is that the max speed of 3200 MT/s for ECC is due to that being the fastest JEDEC standard for DDR4, you're not getting the XMP-profiles to run them faster and will have to resort to manual overclocking.

I was thinking about doing error correction in software at driver/kernel level as opposed to using ECC RAM.

Even though ECC contains the logic of doing error correction in one chip, that doesn't justify double prices.

> about doing error correction in software at driver/kernel level as opposed

I have no clue how that works without significant performance cost

As a sibling said, rhis would certainly come at a huge performance cost. Inline/Inband ECC is showing up again recently, which might be of interest. It comes at a performance cost too, but basically you use regular RAM, and the memory controller issues extra read/writes for the ECC data separately from the rest of the data for a given address.

If that gains traction, it could bring ECC to the masses.

Reply on news.ycombinator.com