Hacker News Reader

Comment by guenthert | Hacker News Reader

My Dell M6800 RAM has 2 bad bits out of 32GiB (easily found with the wonderful 'stressapptest' tool). I'm not exchanging the DIMMs because of that (besides, it's of course in the DIMMs which are more difficult to access). When running Linux I mark a MiB around those memory locations to not be used (memmap option). I haven't bothered to do the same when running MS Windows (it seems a bit more complex). Every once in a while that memory is accessed in a way which causes some corruption leading to a fault. I feel a bit guilty about all those senseless bug reports automatically generated and sent ...

View on HN

Is that tool the same as windows memtest? My brand new pc randomly blue screens twice a month with 'corrupted structure' or something like that, i suspect of ram but windows tool said no errors found after a 3 hour test.

Cant even put it on warranty because it cant be reproduced easily. Cant afford to just start replacing components. 5000€ lemon.

Memtest86+ (http://www.memtest.org) is what hardware enthusiasts use to troubleshoot memory issues despite the built-in Windows memory test being preinstalled and easier to access (no need to boot from a USB, etc) so I'm assuming it's much better than the Windows one.

FYI Last I tried memtest86+ (in June?), it had been outdated for quite some time and downright crashed on newer hardware. The non-free alternative called Memtest86 (by Passmark) works just as well if needed.

Nowadays I use memtest86 that supports UEFI. On Windows, "RAM Test" paidware works well.

There are of course different kind of hardware errors and what appears to be bad memory might be due to some cells being defect or some less-than-perfect bus signals (which then should affect many addresses). In my (limited, perhaps dated) experience (I used it on maybe a few dozen computers), stressapptest (even using the default plain memory test), is much more efficient in finding hardware issues than memtest86+. If stressapptest doesn't find a problem in 30s, memtest86+ won't find any in 24h. I haven't bothered with memtest86+ in years anymore.

EDIT: only ever used the free memtest86+ tool, I have no experience with PassMark's MemTest86.

> some less-than-perfect bus signals

They are also responsible for some mysterious memory compatibility problems in PCs. All PC builders have this experience - on a certain motherboard model, some DIMMs work, some doesn't, but they are all off-the-shelf parts that follow JEDEC standards.

Often there are minor variations in electrical characteristics from DIMMs to DIMMs. If the signal integrity on the motherboard is marginal, there will be mysterious problems.

Try Linpack. It's probably the most stressful of anything I've ever seen, and also a very realistic workload (solving linear equations) --- machines used for scientific computing are doing that all the time. It will stress both the CPU and RAM.

(Many overclockers hate it and think it's "too extreme" because it causes their otherwise "stable" overclocks to instantly fail. I love it because it shows how an unstable system will sometimes effectively calculate 1+1=3. I don't consider a system stable unless it can pass a full day of Linpack without a single error.)

> Many overclockers hate it and think it's "too extreme" because it causes their otherwise "stable" overclocks to instantly fail.

I guess it's okay to game on a system that's right on the verge of failure; what's the worst that happens, your game crashes, maybe you corrupt a drive? Hopefully there's nothing important on it. But I like your regimen for more serious computing.

I'm not exchanging the DIMMs because of that

Why? 1 bad bit, even an intermittent one, is enough for me to condemn RAM. Memory that doesn't remember what was last written is simply not fit for purpose. Even without faulty hardware, most software is already buggy enough as-is.

Because, as stated, the problem can easily be circumvented. Much easier in fact than getting to the DIMMs on the MB (in many other laptops which prioritize low weight and thinness, there wouldn't even be that option unless you're comfortable with a SMD rework station).

Agreed, if the memory would be deteriorating (who knows by which process), the device ought to be replaced. It hasn't however in the last three years, so that seems to have been a singular event (not sure if cosmic rays can permanently damage a RAM cell, but those things are tiny now).

It's much more cost effective to use software to work around hardware failures, then to rely on (never perfectly) dependable hardware -- compare Google FS vs IBM Mainframe.

It's fine if you can recognize all corruption but I doubt in this situation.

> Memory that doesn't remember what was last written is simply not fit for purpose.

IMHO, this means that every memory that's vulnerable to rowhammer and related techniques is defective, and/or has been specified to run at irresponsible refresh timings.

No access pattern should ever be able to change the value of bits not being accessed, that is the definition if faulty memory. And I'm astonished that there isn't a class-action or something.

"Normalization of deviance" comes up a lot lately. It's like the frog being boiled, we just came to accept that 100% of RAM is defective by design.

> we just came to accept that 100% of RAM is defective by design.

Computing itself is broken. Every product from physical to application state is broken in some subtle way which is then countered by a higher layer having some extra code (or component) to adjust it.

But it happens, or it becomes "accepted", at a certain level of complexity. When you're down at the Ben Eater or Gigatron scale, you can prove with simple logic and timing diagrams that every possible machine state is correct.

Somewhere in the quest for higher speeds, RAM runs with timings and refresh intervals that allow rowhammer. And since nobody wants to take the speed hit of having memory that's actually correct, it just.... it's okay now?

Well, I disagree. I'd like to find out how to configure my memory controller to be rowhammer-proof, even if that means a refresh cycle after every single access cycle. And then we can build performance starting from that assumption that correctness is required.

As an old mentor once said, if you start out medium-speed but wrong, you'll get faster at doing it wrong. Start slow but right, and then you get faster at doing it right.

> And since nobody wants to take the speed hit of having memory that's actually correct, it just.... it's okay now?

Yeah, same thing with Spectre... part of the ToS actually states you can't benchmark Intel products with Spectre mitigations applied now (apparently that's a thing)

I wrote pretty much the same thing when rowhammer first came out:

https://news.ycombinator.com/item?id=12409555

Instead of mass recalls and class-action, the authors of memory testing utilities were persuaded to make rowhammer tests optional and off-by-default[1], and there is one with this massive bunch of BS that basically says "it works most of the time so you may choose to ignore it":

https://www.memtest86.com/troubleshooting.htm#hammer

I recall seeing a discussion where someone basically said "100% of RAM would fail this test, so we shouldn't enable it by default" --- conveniently neglecting to mention that older DDR3 and before wouldn't.

Relatedly, I've noticed prices of used RAM, particularly DDR/DDR2, appears to have gone up recently. Other used computer parts are also selling at surprisingly high prices --- 10+-year-old motherboards and CPUs, pre-DDR3 era stuff. I wonder if that's due to decreasing production, increasing demand from retrocomputing enthusiasts, or increasing demand from those who know about this and don't want new RAM anymore.

Reply on news.ycombinator.com