You must log in or # to comment.
Firefox kept crashing on me a few days ago. Decided to run MemTest86 and sure enough. Bad RAM.
Time to make a compromise by buying the cheapest €130 8GB stick.
Luckily for me, I was already running 64GB so now I’m down to 32GB. I can try to wait it out. -_- I don’t really need that much anyway, but I’m glad I had it when it was cheap
Guess Linus was right again to only use ECC RAM.
Which Linus?
Torvalds
Linus when he was with Linus
Let’s spend a ton of extra money minimizing edge case crashing in a browser!!!
🙄
I don’t know about you, but I use my RAM for a lot more than a browser.
What nerd edge case do you want to talk about that is so important you need ECC?
Simple stuff like a calculator can be just as broken by a bitflip as more complex things. You wouldn’t want your calculator to say 1 + 1 = 2049.
If you want to rely on your computer, ECC RAM is required.
Exactly, one of the ‘nerd edge cases’ (as the now removed comment mentioned) is that I use ZFS on my NAS.
There’s lots of checksumming and encryption. Errors in that process are not acceptable and could potentially cause data loss. Since the one of the points of using ZFS is the enhanced data integrity, not using ECC means losing out on that guarantee.
Nobody fucking cares my man. Not important. Nobody in the regular world has ever been effected by not having ECC. You’re inventing edge cases that most cares about. Linus suffers from not understanding normal people.
Nobody in the regular world has ever been effected by not having ECC.
Based on the article, it looks like at least 10% of crashes are caused by not having ECC.
Linus suffers from not understanding normal people.
Well, you are demonstrating that you’re an expert people person so I’ll just have to take your word.
You can’s speak about not having frequent corruption of files when you are not using tools detecting it. I can guarantee you have plenty of already corrupt stuff on your hard drives. RAM bit flips do contribute to that.
You have bugs (leading to broken documents, something failing, freezes, crashes) in applications you use and part of them is not due to developer’s error, but due to uncorrected memory errors.
If you’d try using a filesystem like ZFS with checksumming and regular rescans, you’d see detected errors very often. Probably not corrected, because you’d not use mirroring to save space, dummy.
And if you were using ECC, you’d see messages about corrected memory errors in dmesg often enough.
At what% does this effect the average consumer. And additionally in a critical easy. Can you cite, literally one case, where the presence of ECC would have been critical beyond an occasional annoyance. 1.
The exact numbers for when it messes something up, but keeps running, are unknown and highly ubpredictable.
According to above post, about 10% of firefox crashes (more numbers found in the post) are caused by this stuff. It’s not unreasonable to say those crashes could’ve had the bitflip happen on content instead, changing maybe a character on the page or something.
Note that it’s not 10% of users, as that’s reslly hard to figure out. Someone with bad RAM will likely crash more often.
So no. You’re optimizing around an edge case and something users don’t give a fuck about. Got it. 👍
Bit rot is real, I’ve seen it first hand in plenty of cases. While I tend to blame the storage device, for infrequently accessed files that have been copied multiple times across different drives, I can’t rule out RAM or some other source of the corruption.
Improved overall system stability and data accuracy? With error correction, you can also push performance farther, since you can tolerate a certain amount of errors, instead of needing to aim for 0% error rate.
DDR5 pretty much has ECC built in.
Yeah I can’t remember the last time my browser crashed. No way I’m upgrading all that hardware to avoid something that happens that seldom.
Probably not the use case you’d want to buy ECC for. I considered it for my homebuild because I figured I might process a lot of data at once, and I would appreciate the piece of mind… but I still decided no because I could get more ram for the same price if it were not ECC.
Technically every that happens on a computer is a bit flip 😏
*interest in parity-checking server RAM intensifies*
Well, that’s unnerving.
Figures, sorry.
Wouldn’t that mean ten percent of all crashes in all apps would be caused by bit flips? What makes Firefox special?
You can’t effect the number of bit flips your users hardware has, but you can affect how often buggy code corrupts their memory or otherwise crashes your program.
Let’s say any app will crash about once a year on my machine due to a bit flip. If the app is crap and crashes hundreds of times for other reasons, the bit flip is irrelevant. If the app is robust enough that the bit flip accounts for 10 % of the crashes, that basically means the app is pretty much never crashing due to poor code.
That’s the way people should be looking at it. It basically means hard crashes are extremely rare in the firefox ecosystem.
To be fair, I can’t remember the last time a browser crashed on me in general.
I’ve had Safari of all things crash on me a couple of times. Still, not enough to actually be disruptive.
Anecdotal evidence, but I had both a 13th gen and 14th gen Intel CPU with the bug that caused them to over time, destroy themselves internally.
The most-user-visible way this initially came up, before the CPUs had degraded too far, was Firefox starting to crash, to the point that I initially used Firefox hitting some websites as my test case when I started the (painful) task of trying to diagnose the problem. I suspect that it’s because Firefox touches a lot of memory, and is (normally) fairly stable — a lot of people might not be too surprised if some random game crashes.
I had to turn down my block multiplier so that I could play Unreal Engine games. I would suspect that would extend the lifetime. After the underclock I have perfect stability.
No, they’re saying Firefox uses so much ram they’re far far more likely to be a victim!
Laughs in
Memory: 46.84 GiB / 62.72 GiB (75%)with (probably) several hundred tabs open
It would be interesting to see how this works in Chrome. I would guess that it could be the same - people tend to leave their browsers open with hundreds of tabs and will never reboot their laptops. If you play a random game for 2 hours, bit flips shouldn’t be a problem. But if you keep your browser open for weeks or months with hundreds of tabs, that may cause problems.
What makes Firefox more susceptible to bitflips than any other software? Wouldn’t that mean that 10% of all software crashes are caused by bitflips and it just depends what software you are running when that happens.
I don’t think they’re arguing that Firefox is more susceptible to bit flips. They’re trying to say that their software is “solid” enough that a significant number of the reported crashes are due to faulty hardware, which is essentially out of their control.
If other software used the same methodology, you could probably use the numbers to statistically compare how “solid” the code base is between the two programs. For example, if the other software found that 20% of their crashes were caused by bit flips, you could reasonably assume that the other software is built better because a smaller portion of their crashes is within their control.
Interesting metrics to measure, but since I have no reference to how many crashes are caused by bitflips in any other software, it’s really hard to say if Firefox is super stable or super flaky.
This checks out with Linus Torvalds saying most OS crashes across linux AND windows are caused by hardware issues, and also why he uses ECC RAM.
Programs that use more memory could be slightly more susceptible to this sort of thing because if a bit gets randomly flipped somewhere in a computer’s memory, the bit flip more likely to happen in an application that has a larger ram footprint as opposed to an application with a small ram footprint.
I’m still surprised the percentage is this high.
Is it high? How does it compare to any other software? First time hearing of someone actually measuring this.
No, the exact % depends on how stable everything else is.
Like a trivial example, if you have 3 programs, one that sets a pointer to a random address and tries to dereference it, one that does this but only if the last two digits of a timer it checks are “69”, and one that never sets a pointer to an invalid address, based on the programs themselves, the first one will crash almost all the time, the second one will crash about 1% of the time, and the third one won’t crash at all.
If you had a mechanism to perfectly detect bit flips (honestly, that part has me the most curious about the OP), and you ran each program until you had detected 5 bit flip crashes (let’s say they happen 1 out of each 10k runs), then the first program will have something like a 0.01% chance of any given crash being due to bit flip, about 1% for the 2nd one, and 100% for the 3rd one (assuming no other issues like OS stability causing other crashes).
Going with those numbers I made up, every 10k “runs”, you’d see 1 crash from bit flips and 9 crashes from other reasons. Or for every crash report they receive, 1 of 10 are bit flips, and 9 of 10 are “other”. Well, more accurately, 1 of 20 for bit flip and 19 of 20 for other, due to the assumption that the detector only detects half of them, because they actually only measured 5%.
How many are caused by reddit trashing the Back stack?
The 90% are caused by Fhqwhgads.
Fhqwhgads pushes every bit to the limit.
And ECC memory still isn’t standard in PC computers
God I wish
Lol
