By: rwessel (rwessel.delete@this.yahoo.com), January 7, 2021 6:47 pm
Room: Moderated Discussions
Jörn Engel (joern.delete@this.purestorage.com) on January 7, 2021 4:29 pm wrote:
> rwessel (rwessel.delete@this.yahoo.com) on January 7, 2021 9:25 am wrote:
> >
> > So SECDEC on a 32-bit word requires seven bits, eight bits on a 64-bit word, nine bits on a 128-bit word.
> > Doing that on 64-bit words has the advantage of allowing fairly simple 8x9 or 9x8 RAM configurations.
>
> If the memory interface is 64bit, but the cacheline size is 64 _Bytes_, you need to do 8 reads anyway.
> I wonder how hard it would be to do 9 reads to get the extra ECC information. That would simplify
> things quite a bit, you can use the same DIMMs and motherboards. You can also get away with relatively
> fewer bits for ECC, so it might be possible to reduce overhead from 12.5% to something closer to
> 2.15%. Memory bandwidth is reduced by 11%, which would be fine in my book.
>
> Any CPU manufacturer should be able to do something like that. And I believe I can find old
> implementations of that going back close to 20 years. So why isn't it done all the time?
There was a discussion here of "in band" ECC, which does about what you're describing.
https://www.realworldtech.com/forum/?threadid=198228&curpostid=198228
A problem with your approach is the non-linear addressing of physical memory (although it's not that bad, a shift and add in the addressing path). The overhead is a bigger issue. Doing nine physical memory words for eight addressable words doesn't reduce the overhead, although a more complex scheme might. Crossing DRAM boundaries array is going to be a hit as well, a non-trivial number of 64-byte cache line reads are going to now cross some sort of boundary that will end up needing two separate read operations.
A bigger problem is that you now can't even do the ECC check before reading all nine words. So any optimized cache line loads (critical word first, etc.), become impossible.
Of course those are all performance issues, and may be a suitable tradeoff in some cases.
> rwessel (rwessel.delete@this.yahoo.com) on January 7, 2021 9:25 am wrote:
> >
> > So SECDEC on a 32-bit word requires seven bits, eight bits on a 64-bit word, nine bits on a 128-bit word.
> > Doing that on 64-bit words has the advantage of allowing fairly simple 8x9 or 9x8 RAM configurations.
>
> If the memory interface is 64bit, but the cacheline size is 64 _Bytes_, you need to do 8 reads anyway.
> I wonder how hard it would be to do 9 reads to get the extra ECC information. That would simplify
> things quite a bit, you can use the same DIMMs and motherboards. You can also get away with relatively
> fewer bits for ECC, so it might be possible to reduce overhead from 12.5% to something closer to
> 2.15%. Memory bandwidth is reduced by 11%, which would be fine in my book.
>
> Any CPU manufacturer should be able to do something like that. And I believe I can find old
> implementations of that going back close to 20 years. So why isn't it done all the time?
There was a discussion here of "in band" ECC, which does about what you're describing.
https://www.realworldtech.com/forum/?threadid=198228&curpostid=198228
A problem with your approach is the non-linear addressing of physical memory (although it's not that bad, a shift and add in the addressing path). The overhead is a bigger issue. Doing nine physical memory words for eight addressable words doesn't reduce the overhead, although a more complex scheme might. Crossing DRAM boundaries array is going to be a hit as well, a non-trivial number of 64-byte cache line reads are going to now cross some sort of boundary that will end up needing two separate read operations.
A bigger problem is that you now can't even do the ECC check before reading all nine words. So any optimized cache line loads (critical word first, etc.), become impossible.
Of course those are all performance issues, and may be a suitable tradeoff in some cases.