3 ms·

If a bit flips in a lone workstation and noone is around to see it, does it make a bug? More seriously though, in my experience faulty RAM is generally pretty

by simias 9y ago

If a bit flips in a lone workstation and noone is around to see it, does it make a bug? More seriously though, in my experience faulty RAM is generally pretty easy to diagnose and leads to general system instability. I guess the worst case scenario is generating corrupt data before the issue is diagnosed but again while I would be very wary of that on an database server or something similar, I've never found it to be a massive issue on a workstation (at least if you have decent backups that is). But maybe I've just been lucky so far. But given that the vast majority of consumer-grade computers don't come with ECC and yet RAM issues are still relatively rare I guess I'm not the only lucky one.

jacquesm 9y ago
> If a bit flips in a lone workstation and noone is around to see it, does it make a bug? No, bugs are - these days - considered to be mostly software issues, undetected hardware faults are not bugs in that sense but could lead to data corruption or at a much higher level wrong output. If you don't care at all about the output of your computer (game playing, other recreational use) then not having ECC is fine, but if you do care about your results and you have multiple 10's or even 100's of GB of RAM in your machine then to have the option of ECC is useful. Intel is just using the ECC thing as a way to justify the price difference between their Xeon product line and the consumer stuff. If you ever have to deal with a filesystem that slowly got corrupted because of an undetected memory issue you'll be overnight transformed into an ECC advocate. Keep in mind that those 'decent backups' were made by the machine you do not trust. And god help you if your backups were incremental.
- simias 9y ago
  An other approach is to verify your output (preferably on an other system). Good validation and test suites should be able to catch messed up "output" along with many other non-ECC related issues. I guess it makes sense to have ECC RAM on the machine building your releases (I actually don't even have that at the moment but I wouldn't advocate that...) but for your dev machine does it really matter? I mean, at this point it's really about a rather subjective perception of risk and particular use cases. In my situation I find that memory issues are very low on my list of "things that can go catastrophically wrong". Really the only thing I can think about is building a corrupt release on my non-ECC build server. But from experience I'm not exactly in the minority to do that either and yet I don't observe many such issues in the wild.
  - jacquesm 9y ago
    Verifying your output on another system requires another system, the cost of which handily outweighs the cost of having ECC if the CPU/chipset support it. As for: "I guess it makes sense to have ECC RAM on the machine building your releases" That's a very narrow use case, there are many more usecases than that one and for a lot of those it makes good sense to have ECC: inputs to long running processes, computations that have some kind of real world value (bookkeeping, your thesis, experimental data subject to later verification, legal documents and so on). > but for your dev machine does it really matter? Maybe not to you. > I mean, at this point it's really about a rather subjective perception of risk and particular use cases. No, it's about a thing that if adopted widely would allow us to check off one possible source of errors that would not meaningfully increase the cost of your average machine and would still be an option, nobody would be forced to use anything. > In my situation I find that memory issues are very low on my list of "things that can go catastrophically wrong". Good for you. > Really the only thing I can think about is building a corrupt release on my non-ECC build server. You are still thinking about just your own use-cases. > But from experience I'm not exactly in the minority to do that either and yet I don't observe many such issues in the wild. Likely you also have somewhere between 8 and 32 GB of RAM in your machine. If I look at my servers which have been operating for years on end they do tend to accumulate corrected ECC errors. The only reason I know about it is because there is ECC in there to begin with. If those machines would be running without ECC I'd likely not even be aware of any issues. But maybe the machines or some application on them would have crashed (best possible option), or maybe some innocent bits of data would have been corrupted (second best). And at the far end of the spectrum, maybe we'd have to re-install a machine from a backup (not so good, downtime, extra work) or maybe it would have led to silent data corruption (worst case). Now, servers are not workstations, but my workstation has exactly as much RAM as my servers and no ECC, which is highly annoying but single threaded performance of the various Intel CPUs is much better on the consumer systems than it is on the Xeons unless you want to be subject to highway robbery prices. So for me having the ECC option on consumer hardware would be quite nice, and I suspect anybody else doing real work on their PCs would love that option too.
    - simias 9y ago

by simias 9y ago

jacquesm 9y ago

> If a bit flips in a lone workstation and noone is around to see it, does it make a bug? No, bugs are - these days - considered to be mostly software issues, undetected hardware faults are not bugs in that sense but could lead to data corruption or at a much higher level wrong output. If you don't care at all about the output of your computer (game playing, other recreational use) then not having ECC is fine, but if you do care about your results and you have multiple 10's or even 100's of GB of RAM in your machine then to have the option of ECC is useful. Intel is just using the ECC thing as a way to justify the price difference between their Xeon product line and the consumer stuff. If you ever have to deal with a filesystem that slowly got corrupted because of an undetected memory issue you'll be overnight transformed into an ECC advocate. Keep in mind that those 'decent backups' were made by the machine you do not trust. And god help you if your backups were incremental.

simias 9y ago
An other approach is to verify your output (preferably on an other system). Good validation and test suites should be able to catch messed up "output" along with many other non-ECC related issues. I guess it makes sense to have ECC RAM on the machine building your releases (I actually don't even have that at the moment but I wouldn't advocate that...) but for your dev machine does it really matter? I mean, at this point it's really about a rather subjective perception of risk and particular use cases. In my situation I find that memory issues are very low on my list of "things that can go catastrophically wrong". Really the only thing I can think about is building a corrupt release on my non-ECC build server. But from experience I'm not exactly in the minority to do that either and yet I don't observe many such issues in the wild.
- jacquesm 9y ago
  Verifying your output on another system requires another system, the cost of which handily outweighs the cost of having ECC if the CPU/chipset support it. As for: "I guess it makes sense to have ECC RAM on the machine building your releases" That's a very narrow use case, there are many more usecases than that one and for a lot of those it makes good sense to have ECC: inputs to long running processes, computations that have some kind of real world value (bookkeeping, your thesis, experimental data subject to later verification, legal documents and so on). > but for your dev machine does it really matter? Maybe not to you. > I mean, at this point it's really about a rather subjective perception of risk and particular use cases. No, it's about a thing that if adopted widely would allow us to check off one possible source of errors that would not meaningfully increase the cost of your average machine and would still be an option, nobody would be forced to use anything. > In my situation I find that memory issues are very low on my list of "things that can go catastrophically wrong". Good for you. > Really the only thing I can think about is building a corrupt release on my non-ECC build server. You are still thinking about just your own use-cases. > But from experience I'm not exactly in the minority to do that either and yet I don't observe many such issues in the wild. Likely you also have somewhere between 8 and 32 GB of RAM in your machine. If I look at my servers which have been operating for years on end they do tend to accumulate corrected ECC errors. The only reason I know about it is because there is ECC in there to begin with. If those machines would be running without ECC I'd likely not even be aware of any issues. But maybe the machines or some application on them would have crashed (best possible option), or maybe some innocent bits of data would have been corrupted (second best). And at the far end of the spectrum, maybe we'd have to re-install a machine from a backup (not so good, downtime, extra work) or maybe it would have led to silent data corruption (worst case). Now, servers are not workstations, but my workstation has exactly as much RAM as my servers and no ECC, which is highly annoying but single threaded performance of the various Intel CPUs is much better on the consumer systems than it is on the Xeons unless you want to be subject to highway robbery prices. So for me having the ECC option on consumer hardware would be quite nice, and I suspect anybody else doing real work on their PCs would love that option too.
  - simias 9y ago