Acer hedges its hardware bets, puts vPro and ECC memory in new high-end gaming laptop

Alex/AT said:

With current chip density & RAM amounts, non-ECC memory should just die.

Well, all DDR5 has on-die ECC, AFAIK. The point of that is to mitigate the factors you raised. The sad part is that we can't "see" when our DRAM is starting to have more errors, because they don't expose the error stats.

I don't recall if LPDDR6 extends chip ECC to the host, or if that's rumored for regular DDR6, but I know I read something about that, somewhere.

The reason why standard ECC DIMMs never went mainstream is that they require a 9th chip per rank. With DDR5, it's now 2 extra chips per rank. So, that's 25% higher cost. There's not an OEM on the planet who wouldn't care about that.

My hope is just that in-band ECC becomes more common. Furthemore, it'd be neat if CPUs had support for carving out memory regions with it disabled, so that iGPU performance could be unaffected.

alceryes said:

ECC memory is definitely slower than its non-ECC counterpart.

Yeah, like 1 ns. That's all the time it takes for the host's memory controller to do the checksum, and it should be proportional to the interface speed. The critical path is only 5 gates deep.

Phoronix tested ECC vs. non-ECC DDR5 UDIMMs on a Ryzen 7900X, both @ 4800 MT/s:
"Taking the geometric mean of all 242 results showed no measurable difference to the system performance when ECC was enabled for these Crucial DDR5-4800 UDIMMs."

https://www.phoronix.com/review/amd-ryzen9-ddr5-ecc
So, basically a non-issue, as compared to the impact of LPDDR vs. regular DDR.

bit_user said:

Yeah, like 1 ns. That's all the time it takes for the host's memory controller to do the checksum, and it should be proportional to the interface speed. The critical path is only 5 gates deep.

Phoronix tested ECC vs. non-ECC DDR5 UDIMMs on a Ryzen 7900X, both @ 4800 MT/s:
"Taking the geometric mean of all 242 results showed no measurable difference to the system performance when ECC was enabled for these Crucial DDR5-4800 UDIMMs."https://www.phoronix.com/review/amd-ryzen9-ddr5-ecc
So, basically a non-issue, as compared to the impact of LPDDR vs. regular DDR.

So, you confirmed my point, but then decided to try and minimize it...? That's fine.

I'd rather not take the ~2% throughput hit to use a type of memory I don't even want or need. Not to mention pay the extra cost which is definitely being passed down to the consumer, but to each their own. ;)

alceryes said:

So, you confirmed my point, but then decided to try and minimize it...? That's fine.

Huh? No. Not sure if you're referring to the fact that I edited my post, but that was merely to add real-world benchmark data backing up my assertion.

I actually looked into this, because I wanted ECC memory for our development workstations at my job. I got push-back from a co-worker, who was concerned about latency. Having gone through the process of convincing him is how I knew right off that it was basically a non-issue.

The whole reason I went back and added data was precisely so that you didn't have to take my word for it. You say I minimized it, but now you can just disregard what I said and look at the data for yourself!

alceryes said:

I'd rather not take the ~2% throughput hit

Where are you getting that number? If you look at the Phoronix data, he ran 242 benchmarks and the geomean came out to -0.26%. Sure, among those benchmarks are some outliers, which he highlighted in the article and at the very end.

The point is: for general usage, the effect of ECC is down in the noise. There are lots of other factors that have a bigger impact on system performance than that. If you're doing something that is very latency-sensitive and have tuned up everything else in your system and still need more performance, then it makes sense to bother about the impact of ECC. Otherwise, no.

alceryes said:

to use a type of memory I don't even want or need.

Whether it's warranted really has to do with your tolerance to data corruption. In device I'm just using to watch movies, play games, or browse the web, I'd can pretty much disregard the need for data integrity. In contrast, any type of server or a machine which loads, modifies, and persists complex and high-value data, it's absolutely a bad tradeoff to put negligible performance gains ahead of data integrity.

alceryes said:

Not to mention pay the extra cost which is definitely being passed down to the consumer, but to each their own. ;)

Yes, the cost is really the main stumbling block, IMO. In-band ECC gets around that and doesn't require any special type of memory, but incurs a more substantial performance impact. Still worth it, for machines like servers, workstations, NAS boxes, and robotics applications, but potentially harder to swallow for the average desktop.

From what I understand, processors that did not support system-level ECC were part of a marketing scheme used by Intel after the Pentium III in order charge more to certain customers by delivering less to others. Thankfully such schemes are over, possibly due to Intel no longer having the same market dominance and nearly going bankrupt.

In a way the on-chip ECC in DDR5 is worse than nothing because it hides the internal error rates and correction statistics. This also makes system-level ECC less able to correct errors as the failure modes of memory with on-chip ECC are different. It would be useful if DDR6 reported the on-chip ECC error rates.

ejolson said:

From what I understand, processors that did not support system-level ECC were part of a marketing scheme used by Intel after the Pentium III in order charge more to certain customers by delivering less to others.

My first self-built machine with ECC memory was a Pentium 4. At the time, any of their CPUs would support it, so long as you used a motherboard that offered support. Back then, memory controllers were contained in the "North Bridge" chipset, and not the CPU itself.

The LGA 775 platform was also like that. But, everything changed when the memory controller got integrated into the CPU, starting with the first gen of the "Core i" CPUs (Nehalem). From that point on, you needed both a CPU and a motherboard/chipset that supported it, which they largely restricted (with some exceptions) to their Xeon lineup.

This got relaxed, starting in in Gen 12. I currently have a i5-12600 with ECC memory. At my job, the workstations I mentioned above use i9-12900. But, no matter what CPU, you need a W680 board.

ejolson said:

Thankfully such schemes are over, possibly due to Intel no longer having the same market dominance and nearly going bankrupt.

I wouldn't say "over", because even in the Alder Lake generation, when they threw the doors open, it's not only gated by the motherboard chipset (for no particular reason, since the memory controller is now in the CPU), but also disabled the feature from lower-end models. For instance, you'll find the i5-12400 and below do not support ECC. They use the same silicon as higher-end models that do, but it's mainly a market segmentation thing.

ejolson said:

In a way the on-chip ECC in DDR5 is worse than nothing because it hides the internal error rates and correction statistics.

I feel this, and it's why I still use ECC DIMMs where possible, and in-band ECC on my N97 mini-PC.

ejolson said:

It would be useful if DDR6 reported the on-chip ECC error rates.

Yes, but it's obvious to me why DRAM and DIMM vendors chose not to expose this information. They're using on-die ECC to paper over problems, so they can still sell DRAM chips & DIMMs with some bad cells as "100% working".

Now, a counterpoint to that argument is NAND-based SSDs. These have long (always?) had far more sophisticated error correction, and I never heard anyone getting up in arms about that. I guess the main thing is that NAND has a FTL (Flash Translation Layer) which can actively manage errors by rewriting or moving the data, when it reads a block with some correctable errors.

The equivalent solution for DRAM would be if operating systems used the on-die error reporting to exclude certain memory pages and remap those addresses to a page without errors. Operating systems can already do this (i.e. exclude a list of known bad memory pages), but they don't update it live, based on feedback from the DRAM. Maybe DDR6 will provide feedback so operating systems can start doing that? Would be pretty sweet!