Hacker News Reader

Comment by themitigating | Hacker News Reader

"- If you start getting errors (as in more than the one off cosmic flare) later you can test the memory again and determine it's damaged

- Most memory you buy for builds has a lifetime warranty"

View on HN

You're assuming you have any decent, prompt way of detecting emergent errors before it causes damage. There is none. Whether the corruption hits a pointer (likely to cause a crash) or a tax document is effectively completely random.

If it crashes then you know the error has occurred, you can then test for that error.

A lot of damage can be done before you get an obvious memory-induced crash. Software crashes all the time for reasons other than memory issues, even someone with deep technical knowledge wouldn't necessarily jump to that conclusion. And everyone else would A) probably never even think of the possibility, B) not know how to test their memory, C) probably buy a whole new laptop instead

That's assuming the thing you are currently doing is what crashes, and not instead creating data (a document, a compiled binary, a financial transaction, a crypto key) which is silently corrupted and the corruption is only detected way later. C.f. xerox photocopier bug (not saying that was a memory bug, example is an insidious bug).

https://www.dkriesel.com/en/blog/2013/0802_xerox-workcentres...

I've had memory errors make many directory entries disappear in one directory on XFS, noticed only months later. When you write out bad data and the computer says everything is fine, you won't necessarily be able to get your data back.

So let me understand this. Your data is important and you don't want even rare errors to occur, so you want ECC memory. However you use a non-journaling file system which is more likely to lose data?

> XFS is a high-performance 64-bit journaling file system

https://en.wikipedia.org/wiki/XFS

(and I don't use XFS any more.)

Journaling won't help as the errors are in memory 1st - then replicated to the disk.

It feels like arguing in bad faith. How did you arrive to the point XFS is non-journaling to begin with?

How a journaling FS would help in case of writing data corrupted in memory, @themitigbting?

And if it doesn't help, then why you decided to bring it as an argument?

NB: even if you use ZFS you still need backups.

all those points are irrelevant - when you do work with you computer, not just being frustrated your game has crashed.

running a memtest overnight is hardly a good choice.

"So the only danger of not having ECC is exceedingly rare memory errors. If those rare instances mattered that much then you should get ECC but for everyone else how is it worth it?"

The fact DDR5 has auto-error correction for the data that has arrived to the memory chip should tell the story. Still not full ECC as the latter requires cooperation w/ the memory controller, yet the price in material is there already. But yes, w/o any shadow of a doubt - the 1st and most important part of any program is correctness, optimization come afterwards.

The internal ECC of DDR5 is not good enough. Its only purpose is to restore the reliability of DDR5 to the level of DDR4, despite having smaller cells and higher throughput.

The only useful ECC for the user is the one computed in the memory controller inside the CPU, stored in the DRAM and verified after returning to the memory controller.

This allows the CPU to be aware of any error and it also corrects or detects the errors caused by electrical noise on the PCB traces or by bad memory sockets, not only those caused by bit flips inside the memory cells.

Reply on news.ycombinator.com