On 1/8/2015 3:40 PM, david wrote:
Thanks for your comments. In the particular application, I used the word "server" only in the sense that GUI is only rarely used, and CPU speed isn't an issue. The data the server holds has other "primary" copies elsewhere, so if some corruption or damage occurs, it can be restored within acceptable time. Thus, I am not interested in ECC memory or RAID for this situation, although I do appreciate the need for servers with mission-critical data. As a former employee of Tandem Computers, mirroring, backup, check-everything, dual everything is in my blood.
the problem with non-ECC memory is, you never KNOW when data corruption has happened. Making life more complicated, the statistical rate of these soft bit errors varies widely from machine to machine as a significant cause is background radioactivity, and other components of the system such as the chassis materials can contribute to this. I've seen numbers ranging from a few errors per century per gigabyte to a few per HOUR per gigabyte. without ECC, you simply don't know this has happened, unless the flipped bit happens to be in some code in a place and position where it causes the code to crash, or you happen to notice corruption, such as a block decode error while playing a video (which, for formats like mpeg/mp2/mp4 can cause video block glitches for several seconds until a new I-frame restores the whole picture).
I really wish the PC industry made ECC the norm even for desktop workstations. it only adds 12% to the memory cost (9 bits instead of 8 bits per byte, or 72 instead of 64 per word), and the memory cost is typically about a 10th of the total system price, such that the cost of ECC would only be 1% or so.... but since ECC is 'special server only' stuff, it costs a premium far above and beyond that 12%.
-- john r pierce 37N 122W somewhere on the middle of the left coast _______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos
