Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ECC matters

realworldtech.com

Post reply on HN
Print view View original

501–510 of 567 posts

Re: ECC matters

#501

Post by tomxor »

axiolite wrote: post #448
Jedd wrote: post #439

Earlier quoted context omitted.

At some point, whatever's watching the watchers is going to be vulnerable to bitflip and similar problems. Even with a triple-redundant quorum mechanism, slightly further up that stack you're going to have some bit of code running that processes the three returned results - if the memory that's sitting on gets corrupted, you're back where you started.

> At some point, whatever's watching the watchers is going to be vulnerable to bitflip One advantage of microkernels is that the "watcher" is so small that it could be run directly from ROM, instead of loaded into RAM. QNX has advocated that route for robotics and such in the past. Minix may not be the best example of the type. While it is a microkernel, it's real world reliability has been poor in the past. More mat…

> Minix may not be the best example of the type. While it is a microkernel, it's real world reliability has been poor in the past. More mature microkernel operating systems like QNX and OpenVMS are better examples.

You might be referring to the previous versions. Minix 3 is basically a different OS, it's more than an educational tool - in fact it's probably running inside your computer right now if you have an Intel CPU (it runs Intel's ME chip - for better or worse).

Re: ECC matters

#502

Post by lynguist »

mlyle wrote: post #241
ReactiveJelly wrote: post #223

Earlier quoted context omitted.

Back when my daily driver was a Core 2 laptop, someone told me that capping the clock frequency would make it unusable. As a petty "Take that", I dropped the max frequency from 2.0 GHz to 1.0 GHz. I ran a couple benchmarks to prove the cap was working, and then just kept it at 1.0 for a few months, to prove my point. It made a bigger difference on my ARM SBC, where I tried capping the 1,000 MHz chip to 200 or 400 MHz…

The funny thing is, on modern processors-- throttling TDP only affects when running flat out all-core workloads. A subset of cores can still boost aggressively, and you can run all-core max-boost for short intervals. And the relationship between power and performance isn't linear as processor voltages climb trying to squeeze out the last bit of performance. So if you want to take a 105W CPU and ask it to operate in a…

You’re giving up 0 of peak single thread performance. A single core in turbo across Intel and AMD, mobile and desktop uses max 50W.

Re: ECC matters

#503

Post by tomxor »

Jedd wrote: post #439
tomxor wrote: post #403

Earlier quoted context omitted.

> Making software resilient against bitflips in memory seems very difficult though, since it not only affects data, but also code. There is an OS that pretty much fits the bill here. There was a show where Andrew Tanenbaum had a laptop running Minix 3 hooked up to a button that injected random changes into module code while it was running to demonstrate it's resilience to random bugs. Quite fitting that this discussi…

At some point, whatever's watching the watchers is going to be vulnerable to bitflip and similar problems. Even with a triple-redundant quorum mechanism, slightly further up that stack you're going to have some bit of code running that processes the three returned results - if the memory that's sitting on gets corrupted, you're back where you started.

Yes, but this is the entire principle around which microkernels are designed: making the the last critical piece of code as small and reliable as possible. Minix3's kernel is As far as bitflips are concerned, having the critical kernel code occupy fewer bits reduces the probability of a bitflip causing an irrecoverable error.

Re: ECC matters

#504

Post by versteegen »

shrewduser wrote: post #500
klodolph wrote: post #485

Earlier quoted context omitted.

Just because capitalism fails to provide something does not mean that communism would solve the problem, or that criticism of capitalism as a system is uncalled for. This is not some kind of binary capitalism/communism world we live in.

i'm just struggling to find the link between capitalism and ECC memory.

Market segmentation.

Re: ECC matters

#505

Post by eptcyka »

shrewduser wrote: post #500
klodolph wrote: post #485

Earlier quoted context omitted.

Just because capitalism fails to provide something does not mean that communism would solve the problem, or that criticism of capitalism as a system is uncalled for. This is not some kind of binary capitalism/communism world we live in.

i'm just struggling to find the link between capitalism and ECC memory.

It's the act of maximizing profits by segmenting the market that creates artificially bad products that end up being the mainstream because of the price difference. If the companies responsible for making these decisions were optimizing just a tad bit more for practicality and usability rather than just profit, ECC would be the standard and that would be the end of that. Similar to how a lot of luxury and non-luxury cars will have seemingly essential and cheap equipment only available as part of an expensive options package - the cost of producing and installing the extra equipment is a mere fraction of the total package cost, a large majority will end up buying the package anyway (and 100% would if money was no object). One might argue that this practice is part and parcel of modern industrial markets, and is almost fair - prices are arbitrary and consumers get to pay for the value they get out of something, there is no optimal, moral way to determine what someone's margins should be, yadda yadda. In my opinion, usually the market will choose what are acceptable margins on a given product and/or service, but with 2 thousand dollar parking sensors and double-the-price ECC memory, with artifical segmentation, I'm paying not for the manufacturing and delivery of a product with a feature I want, but instead I'm having to pay for the opportunity of being able to have the product with the features I want + the manufacturing and delivery.

Re: ECC matters

#506

Post by Noxmiles »

I was reading it and thought: wow, this guy is absolutely right! Great things he's talking about. After reading it, i saw it was Linux Torvalds :D

Re: ECC matters

#507

Post by aquadrop »

Jedd wrote: post #439
tomxor wrote: post #403

Earlier quoted context omitted.

> Making software resilient against bitflips in memory seems very difficult though, since it not only affects data, but also code. There is an OS that pretty much fits the bill here. There was a show where Andrew Tanenbaum had a laptop running Minix 3 hooked up to a button that injected random changes into module code while it was running to demonstrate it's resilience to random bugs. Quite fitting that this discussi…

At some point, whatever's watching the watchers is going to be vulnerable to bitflip and similar problems. Even with a triple-redundant quorum mechanism, slightly further up that stack you're going to have some bit of code running that processes the three returned results - if the memory that's sitting on gets corrupted, you're back where you started.

You can have two watchers watching each other's integrity.

Re: ECC matters

#508

Post by artifact_44 »

tomxor wrote: post #403
maria_weber23 wrote: post #274

Earlier quoted context omitted.

ECC memory can't eliminate the chances of these failures entirely. They can still happen. Making software resilient against bitflips in memory seems very difficult though, since it not only affects data, but also code. So in theory the behavior of software under random bit flips is well... Random. You probably would have to use multiple computers doing the same calculation and then take the answer from the quorum. I…

> Making software resilient against bitflips in memory seems very difficult though, since it not only affects data, but also code. There is an OS that pretty much fits the bill here. There was a show where Andrew Tanenbaum had a laptop running Minix 3 hooked up to a button that injected random changes into module code while it was running to demonstrate it's resilience to random bugs. Quite fitting that this discussi…

another past approach: https://en.wikipedia.org/wiki/Tandem_Computers

Re: ECC matters

#509

Post by SideQuark »

incrudible wrote: post #424
SideQuark wrote: post #382

Earlier quoted context omitted.

>Bitflips are not the root cause here. So those systems didn't fail when a bitflip happened? > The root cause is that somebody engineered something life-critical that mistakenly assumed hardware can not fail. The systems I am aware of were designed with bitflips in mind. NO software can handle arbitrary amounts of bitflips. ALL software designed to mitigate bitflips only lower the odds via various forms of redundancy…

> So those systems didn't fail when a bitflip happened? I didn't say that. I'm saying that the root cause (as in "root cause analysis") is not the bitflip. Designating the bitflip as the root cause is like analyzing your drunk driving accident and concluding that the root cause must be ethanol, rather than your drinking habits. > The systems I am aware of were designed with bitflips in mind. NO software can handle ar…

>I don't care how often it happens.

Yes, that is clear.

> If you have solved the problem of data integrity...

As above, this is not a binary, black and white thing, but you keep presenting it as such. It's probabilistic, and higher protection is not free - the tradeoff is engineering.

> Redundancy alone reduces the probability of spurious failure by several magnitudes

ECC "alone reduces the probability of spurious failure by several magnitudes". That's why it is used.

Naive redundancy ignores almost a century of better method form forward error correcting codes. I have a feeling your idea of redundancy is having multiple exact copies of a system or data and having them vote, which is a terribly expensive way to do data protection when there are vastly better methods.

>Of course, somebody who sells ECC RAM will want to convince you that ECC actually solves a real problem. The same can be said about the nutritional supplement industry, or many other industries that rely on make-belief.

And we're done. If you don't think ECC helps a real problem then I see why you don't understand bitflip causing problems. Good luck.

Re: ECC matters

#510

Post by joshspankit »

srtjstjsj wrote: post #468
apankrat wrote: post #379

Earlier quoted context omitted.

Aye. I have an assert in the code that fronts a very pedantic test of the context. In all cases when this assert was tripped (and reported) an overnight memtest86 test surfaced RAM issues. - Edit - Also, bit flips in the non-ECC memory are _the_ cause of the "bitrot" phenomenon. That is when you write out X to a storage device, but you get Y when you read it back. A common explanation is that the corruption happens _…

Bitrot in human memory is the same. Memories change during the process of recalling them, not while they are in "storage".

Hard to say for sure since we can’t measure “bit“ flips in-brain
Post reply on HN