3 ms·
500+ comment thread 3 days ago: https://news.ycombinator.com/item?id=25622322 https://news.ycombinator.com/item?id=25622322. One thing I didn't glean from eith
by manfredo 6y ago
500+ comment thread 3 days ago: https://news.ycombinator.com/item?id=25622322 https://news.ycombinator.com/item?id=25622322.
One thing I didn't glean from either article, though, is why ECC ram needs to be implemented in both the CPU and the RAM. Is the concern that corruption could occur either inside the CPU's memory (registers, Caches) or inside the RAM module and hardware needs to exist in both? If so wouldn't that still mean that having ECC RAM modules would still prevent the latter? I had the understanding that RAM is meant to function largely agnostic of the CPU using it.
- jnwatson 6y agoMost of the logic resides in the memory controller, and the extra bits for the checksum reside in DRAM. You need a little logic in the OS to report correction and uncorrectable events.
- shawnz 6y agoWhy can't you just reserve portions of the usable RAM for the checksum bits? You could even potentially have different parity levels for different applications depending on need.
- mjevans 6y agoThink about how CPUs access RAM, Random Access Memory. Now think about how you would store and process the ECC (checksum / parity data) without the optimally dispersed bits. This is very much like RAID-5,6,Z or like the addition of integrity codes in other media. CDs and DVDs have the ECC protected data as the default layer and also expose the raw blocks to the OS. Random seeks in a CD / DVD were possible because the device could start reading from anywhere and get back a full stream of data. With RAM used the same way the first question is: Where is the ECC decision drawn? Is it per bus word (E.G. 128 or 256 bits), an OS page (often 4KByte for common OSes), some other unit? Next is where is the ECC data stored? If you're keeping this efficient smaller reads are better, and the 4KByte OS page is a common multiple for lots of things so at the moment that's about where I'd draw the line. Dedicating silicon to calculate the parity on a page that large is probably way more expensive than gates for a couple extra bits per native word (and designs that might also match parity used for internal cache too and thus could be reused), but would be a logical maximum for doing something the hard way. Virtual page alignment would also be a performance issue, and the cache would have an effectively fixed blocksize and read-ahead granularity. Or everyone could just use the one already developed industry standard that was optimized by engineers not thinking on the back of a napkin.
- fulafel 6y agoIt doesn't. I recently read somewhere that Intel had not long ago put out some embedded CPU products that can do it with non-ECC RAM, maybe someone with better memory can find a link.
- redis_mlc 6y agoCan you expand the pronoun "it" so your comment is less ambiguous? Thanks.
- fulafel 6y agoECC ("it") doesn't need to be implemented in both CPU and RAM.
- manfredo 6y agoInteresting, so validation of the parity bits occurs in the CPU? Presumably when data is read off the bus.
- wmf 6y agoIntel calls this in-band ECC and it's in their Elkhart Lake Atom SoC. https://www.anandtech.com/show/16102/intel-launches-10nm-atom-embedded-cpus-elkhart-lake-now-available https://www.anandtech.com/show/16102/intel-launches-10nm-ato... This is pretty inefficient compared to regular ECC but you can't really do regular ECC with LPDDR4. Nvidia also implemented something similar years ago.
- fulafel 6y agoInteresting. Nvidia indeed mentions this at https://developer.nvidia.com/blog/inside-pascal/ https://developer.nvidia.com/blog/inside-pascal/