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