Fantastic burn by Linus Torvalds whom also had some skin in the CPU game.
Offtopic, I wonder if he trawls that site regularly. And eventually I wonder, is he here also? :)
ECC matters
231–240 of 567 posts
Re: ECC matters
#232I have multiple times postponed buying new computers for YEARS, because I'm waiting for intel to get their head out of their ass and actually let me buy something that does ECC for desktop. (incl laptops)
I would have bought computers when I "wanted one". Now I buy them when I need one. Because buying a non-ECC computer just feels like buying a defective product.
In the last 10 years I would have bought TWICE as many computers if they hadn't segmented their market.
Fuck intel. I sense that Linus self-censored himself in this post, and like me is even angrier than the text implies.
Re: ECC matters
#233Earlier quoted context omitted.
When you say bitflips were "common" on thousands of physical machines, does that mean you observed thousands of bitflips? Otherwise, I would think that an unlikely event becoming 1000x more likely by sheer numbers would have warped your perception. I believe that hardware reliability is mostly irrelevant, because software reliability is already far worse. It doesn't matter whether a bitflip (unlikely) or some bug (li…
Ya, I'm not buying that biyflips are a problem. Or maybe modern software can correct better for this? Because I use my desktop all day everyday running tons of software on 64 gb of ram and I don't get errors or crashes often enough to remember ever having one.
> I'm not buying that biyflips are a problem.
Google and read up - it is a problem, has killed people, has thrown election results, and much more.
It's such a common problem than bitsquatting is a real thing :)
Want to do an experiment? Pick a bitsquatted domain for a common site, and see how often you get hits.
Re: ECC matters
#234Earlier quoted context omitted.
While it's true that Intel only has ECC support on Xeon (and several other chips targeted at the embedded market) it's not true that ECC is supported well on AMD. We only use Xeons on developer desktops and production machines here precisely because of ECC. It's about 1 bit flip/month/gigabyte. That's too much risk when doing something critical for a client.
> it's not true that ECC is supported well on AMD ECC is supported on most Ryzen models[1], as long as the motherboard supports it. In fact, ASUS and ASRock (possibly others) have Ryzen motherboards designed for workstation/server use where ECC support is specifically advertised. [1] The only exception is the Ryzen CPUs with integrated graphics.
Depends what you mean by supported. Semi-offically:
ECC is not disabled. It works, but not validated for our consumer client platform.
Validated means run it through server/workstation grade testing. For the first Ryzen processors, focused on the prosumer / gaming market, this feature is enabled and working but not validated by AMD. You should not have issues creating a whitebox homelab or NAS with ECC memory enabled.
https://old.reddit.com/r/Amd/comments/5x4hxu/we_are_amd_crea...
Re: ECC matters
#235Earlier quoted context omitted.
Another comment[1] mentioned 1 bitflip per gigabyte per month. If you have a lot of RAM, that's rather a lot. > It doesn't matter whether a bitflip (unlikely) or some bug (likely) causes a node to spuriously fail Except that a bitflip can go undetected. It may crash your software or system, but it also may simply leak errors into your data, which can be far more catastrophic. [1] https://news.ycombinator.com/item?id=…
So can a bug.
Yes. And? That doesn't suddenly make bitflips benign.
Re: ECC matters
#236Earlier quoted context omitted.
> but even low-end Ryzen Threadripper CPUs have TDP of 180W, which is a bit higher than I'd like. Why does it matter? It doesn't idle that high; it only goes that high of you're using it flat out, in which case the extra power usage is justified because it's giving that much more performance over a 100 W TDP CPU. Now I totally get it if you don't want to go Threadripper just for ECC because it's more expensive , but…
> I've never seen anyone shop a desktop CPU by TDP, rather than by performance and price. That's me. When I start to plan for a new system, I select the processor first and read its thermal design guidelines (Intel used to have nice load vs. max temp graphs in their docs) and select every component around it for sustained max load. This results in a more silent system for idle and peace of mind for loading it for ext…
Built a NAS. My #1 concern for choosing CPU was TDP. This machine is on 24/7 and power use is a primary concern where I live because electricity is NOT cheap.
Re: ECC matters
#237I still remember Craig Silverstein being asked what his biggest mistake at Google was and him answering "Not pushing for ECC memory."
Google's initial strategy (c. 2000) around this was to save a few bucks on hardware, get non-ECC memory, and then compensate for it in software. It turns out this is a terrible idea, because if you can't count on memory being robust against cosmic rays, you also can't count on the software being stored in that memory being robust against cosmic rays. And when you have thousands of machines with petabytes of RAM, those bitflips do happen. Google wasted many man-years tracking down corrupted GFS files and index shards before they finally bit the bullet and just paid for ECC.
Re: ECC matters
#238Earlier quoted context omitted.
I ran a memory test for two weeks straight on a consumer laptop with 8 GB RAM and could not get a single bit flip, so your mileage may vary.
How did you run those tests? From what I understand on the topic, for your results to be statistically significant you need at least hundreds of machines and very rigid testing methodology.
As someone who also ran a similar test myself and haven't seen a bit flip, I'm also skeptical of the 96% figure.
I'm too lazy to run the exact numbers right now, but with "4 GB, 96% percent chance, three days" as the hypothesis, I think you'll find that an experimental result of "8 GB, 0% chance, 14 days" is highly statistically significant.
Edit: rough back of napkin estimate - you're not seeing an event in roughly 10x trials (2x number of bits and ~5x number of days). Given hypothesis is true your experimental result has a probability of (1-0.96)^10 = very very small. Conclusion: hypothesis is false.
Re: ECC matters
#239Earlier quoted context omitted.
When you say bitflips were "common" on thousands of physical machines, does that mean you observed thousands of bitflips? Otherwise, I would think that an unlikely event becoming 1000x more likely by sheer numbers would have warped your perception. I believe that hardware reliability is mostly irrelevant, because software reliability is already far worse. It doesn't matter whether a bitflip (unlikely) or some bug (li…
Ya, I'm not buying that biyflips are a problem. Or maybe modern software can correct better for this? Because I use my desktop all day everyday running tons of software on 64 gb of ram and I don't get errors or crashes often enough to remember ever having one.
Crashes aren't such a big problem. You can detect them and reboot or whatever. Silent data corruption is the real issue IMHO.
See also this comment above: https://news.ycombinator.com/item?id=25623764
Re: ECC matters
#240For those out of the loop like me, ECC does indeed stand for error correcting code. https://en.m.wikipedia.org/wiki/ECC_memory