Replies to post #1622 on Advanced Micro Devices Inc (AMD)

[Elmer Phud]

UpNDown -

Perhaps it's time you and Elmer got a refresher course on ECC and CRC.

No need, I know what it is. The point I made was that ECC can correct an error while CRC requires a retransmit. On a shared bus ECC is in parallel with the data. Corrupted data can be corrected on the fly, no bandwidth penalty. CRCs must be attached to the data packet and therefore always consume bandwidth even when there is no data corruption. Corrupted data must be retransmitted, further consuming bandwidth. What this means is that the bandwidth claims of aHT is somewhat misleading.

[wbmw]

Re: Perhaps it's time you and Elmer got a refresher course on ECC and CRC.

Thanks, but it wasn't necessary. I am quite familiar with both techniques.

There is obviously no need to transfer an ECC code inside a packet of data that is CRC protected. If the CRC is correct, we're happy.

On the contrary, you would be making a huge architectural mistake if you include CRC without ECC. Just ask Sun. They had to recall a number of UltraSparc II systems when their caches became corrupted with double-bit errors. The problem with CRC is that it only identifies errors in the packet data itself, which is encoded at the protocol level. If the error happens before this, then the CRC will be correct, but the data will still be corrupted.