Re: ECC and CRC on aHT
Love starting with 3-letter acronyms :).
Perhaps it's time you and Elmer got a refresher course on ECC and CRC.
Error correcting codes can be designed to allow any level of error detection and correction. By ECC in this context I believe we're talking about a SECDED error correcting code. SECDED means Single Error Correction and Double Error Detection. That means that if a single bit were toggled in the data plus ECC bits, we would be able to detect and correct the error. If exactly two bits were toggled in the data plus ECC bits, we would be able to detect that, but not correct it. If more than two bits are changed for the original correct message, all bets are off. We certainly can't correct the error and may not even detect it.
CRC or cyclic redundency check, is a way of hashing the data in a message to compute a checksum. The hashing algorithm is designed to spread the information content of the original data throughout the final checksum value so that any invalid data/packet will be detected except in the highly unlikely case that exactly the right bits are changed to miraculously come up with the same CRC value. With 32-bit CRC values this would mean about a 4 billion to one chance that some random change in a good number of the bits would not be detected. All single bit errors will be detected.
CRC is used to detect validity of a message that can be resent from a repository that holds a true copy of the data and can be asked for a new copy, should the first transmission be in error. For Opteron aHT transfers, this makes sense. First, the size of the data record is variable. Second, if a transmission is made with an error in it (random background radiation, anyone?) a resend request can be made for the data. The sending aHT device -- another Opteron, an 8511, 8311 or 8111, or whatever -- will have a copy of the message or can reconstruct one and resend.
ECC is used when the transmission cannot be resent. For instance, on your audio CDs, ECCs are used because you still want to get the most of the music even if there are some errors. Similarly, RAM chips sometimes go bad. Doesn't matter how many times you ask for the data, you aren't going to get it. If the correct data can be reconstructed using an ECC then the information needed can be saved elsewhere, and that RAM module can be disabled for future use (as a subsequent corruption of the chip might render the situation unrecoverable).
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. To say "Since AMD does not have this, they are risking some reliability issues" is ridiculous.
As for whether AMDs cHT protocol (coherent HyperTransport) is CRC protected, we don't know. They haven't published the specs. But the aHT controllers in these chips perform CRC checking in hardware, so there is little slowdown, aside from transmission time of the checksum itself -- and how can you check anything without it? But cHT could be done using ECC if AMD wished, it's a proprietary protocol.
AI
