DIMM vs. Udimm vs. Rdimm vs. Sodimm vs. Cudimm: What's the Difference?

I think the bigger performance problem is that a read burst from one channel of RAM is no longer matched to the CPU cache line size when doing in-band ECC.

This is true, however, with the readahead cpu's usually do anyway, I don't even think it's that bad.. There is definitely a performance and capacity cost, but again, technically, that capacity cost is also present in ECC memory, that extra memory is still there, it's just not printed on the label, and instead, the stick is more expensive..

The cpu cache won't be mismatched though, since the memory controller can mask this. The performance hit will be due to the memory controller having to do the extra reads for parity.

That will be a tiny mismatch, and I wonder if the performance implication of this won't more or less be equal to the performance difference we already have between buffered and unbuffered memory (more or less the same, simply, now that "extra work", moved from inside the dimm, to the memory controller)

The chips with in-band ECC have a separate dedicated cache for storing ECC codes, which are stored in another part of the memory chip, not inline with the corresponding cache line that stores data.

So the burst transfers have the same size as when ECC is disabled.

Without the special cache, the number of memory accesses would double, for data and for the extra ECC bits, which would not be acceptable. With the ECC cache, in many cases the reading and writing of the extra ECC bits can be avoided.

There have been published a few benchmarks for inline ECC. The performance loss depends on the cache hit rates, so it varies a lot from program to program. In some cases the speed is lower by only a couple percent, but for some applications the performance loss can be as high as 20% or 30%.