ECC与DDR5

# ECC 和 DDR5 来源：https://etbe.coker.com.au/2026/07/19/ecc-ddr5/ ## 汉明码 ECC RAM 可在数据到达 CPU 之前纠正内存中出现的错误。最常见的 ECC 形式是 [汉明码 [1]](https://en.wikipedia.org/wiki/Hamming_code)，当拥有 R 个冗余位时，它能够纠正 2^R-R-1 位数据中的单位错误，并检测双位错误。对于 PC 应用而言，若要保护 32 位数据，需要 R=6；而要保护 64 位数据，则需要 R=7。DDR4 及类似内存的标准是总线上数据宽度为 72 位，并利用汉明码为 65 位数据纠正单位错误、检测双位错误。我们使用的计算机具有 64 位数据，因此多出一个额外的校验位，但我不清楚这个额外位具体作何用途。 ## RDIMM 与 UDIMM 的区别 这方面的一个混淆点是[注册内存（即 RDIMM）[2]](https://en.wikipedia.org/wiki/Registered_memory) 与常规 PC/笔记本电脑内存（通常称为 UDIMM）之间的区别。“寄存器”只是一个缓冲器，由于一些与本帖无关的复杂问题，它允许使用更大的 DIMM 并在系统中安装更多 DIMM，但延迟可能稍差。从技术上讲，完全可以制造不带 ECC 的 RDIMM（宽度为 64 位而非 72 位），但我从未见过使用此类内存的系统。 我曾使用过不少配备 ECC UDIMM 的系统，并建议尽可能避免使用，因为 ECC UDIMM 在二手市场上价格昂贵，而 ECC RDIMM 则可能非常便宜。有些配备 ECC RDIMM 的服务器非常不适合家用（例如双 CPU 1U 服务器，噪音极大），因此一旦超过 5 年税务折旧期，服务器机箱就会被送往电子垃圾回收站，内存则流入二手市场。大量缺乏配套系统的内存迫使价格下跌。 在常见系统中，有带 ECC 的 RDIMM 系统和不带 ECC 的 UDIMM 系统。 ## Chipkill 如果 RAM 中的每一位都完全独立于其他位，那么基本的汉明码就能解决大部分问题。然而，同一芯片中的多个位可能受到同一问题的影响，或者 DIMM 上的一个芯片可能完全失效。每个 RDIMM 拥有 18 或 36 个 DRAM 芯片，每个芯片对应 2 或 4 位。在具有 36 个 DRAM 芯片的 DIMM 上，一个芯片失效可通过汉明码可靠检测。而在具有 18 个 DRAM 芯片的 DIMM 上，一个芯片失效不一定能被汉明码检测到。IBM 已将术语 [ChipKill 注册为商标，用于能够应对单个 DRAM 芯片失效的 ECC 系统 [3]](https://en.wikipedia.org/wiki/Chipkill)。这在戴尔和惠普服务器上被称为“高级 ECC”，要求 DIMM 数量为偶数。如果有人知道“ChipKill”类型系统使用的编码方法，请告知。 配备高级 ECC 的系统通常还具有热备内存和类似 RAID-1 的功能，这很有趣，但大多数阅读我博客的人可能永远不会用到。 ## DDR5 [DDR5 具有片上 ECC，以应对因内存变小、变快而增加的错误发生率 [4]](https://www.atpinc.com/tw/blog/ddr5-what-is-on-die-ecc-how-is-it-different-to-traditional-ecc)，规格为每 128 位数据配备 8 位纠错能力，这暗示了基本的汉明码。 片上 ECC 并不能替代常规 ECC，它只是针对新引入问题的缓解措施。根据我的内存错误经验，大多数可重复的错误（即系统反复在 Memtest86+ 或 ECC 错误报告中显示错误）都是 DIMM 接触问题，拔出并重新插入相关 DIMM 后，相同测试便能通过。这些错误不会受到片上 ECC 的影响。 我担忧的一点是，片上 ECC 可能与主板上的 ECC 相互作用，从而降低其有效性。我未能找到足够的信息来确定是否如此。我的担忧是，一个被基本汉明码纠正的 3 位或更多位的错误，可能比原始错误更有可能产生“高级 ECC”无法修复的错误状态。 目前，关于 ECC 对 RAM 错误有效性的最佳公开研究是 [2009 年发表的 Google 论文，基于 DDR 和 DDR2 内存 [5]](https://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf)。因此，我预计短期内不会看到关于甚至 DDR4 ECC 的公开研究。我推测 Google 和其他云提供商仍在进行此类研究，并在保密协议下向 DRAM 供应商提供信息，因此我们只能寄希望于 DRAM 供应商采取必要措施确保一切正常，并允许我们购买基于这些研究的产品。 ## DDR5 EC4 与 EC8 [DDR5 支持 2×32 位的"子通道"，而不是仅支持 64 位字 [6]](https://en.wikipedia.org/wiki/DDR5_SDRAM#Subchannels)。对于 DDR5 ECC RAM，存在 EC4 变体（每个子通道 36 位数据）和 EC8 变体（每个子通道 40 位数据）。EC8 允许在每个子通道上独立使用汉明码。我尚未找到关于 EC4 具体工作原理的参考资料——它可能一次读取 64 位（不利用子通道）以使用汉明码，或者每个子通道拥有 1 个校验位，并且仅在该子通道校验失败时才检查汉明码。EC8 允许对 32 位数据进行完整的汉明码校验，并可能支持对 64 位数据的 ChipKill。 广泛的说法是，所有 DDR5 RDIMM 均为 EC8，所有 DDR5 ECC UDIMM 均为 EC4。在 eBay 上快速搜索发现，有广告显示 EC4 和 EC8 RDIMM 皆有，且链接到看似可靠的网站，确认部分 RDIMM 是 EC4。有报告称存在 EC8 UDIMM，尽管我无法找到任何广告。这似乎与 DDR4 的情况类似：非 ECC RDIMM 似乎在某些地方仍然存在，而 ECC UDIMM 我用过几次，但大多数人从未见过。 随后我搜索了有关服务器支持的信息。戴尔 R760 服务器同时支持 EC4 和 EC8 RDIMM，但两者不能在同一系统中混用。 EC4 DIMM 的存在是错误的。不应该制造这种低规格的硬件，72 位和 80 位宽 DIMM 之间的制造成本差异并不大，最终结果是某些系统规格不足，并且在升级系统时需要检查更多兼容性，增加了难度。 ## 为什么需要 ECC [这里有一篇有趣的文章，提到 Mozilla 声称 15% 的 Firefox 崩溃是由 RAM 硬件错误引起的 [7]](https://www.tomshardware.com/pc-components/ram/bit-flips-cause-up-to-15-percent-of-firefox-crashes-asserts-mozilla-engineer-figure-inferred-from-470-000-auto-submitted-crash-reports)，这似乎基于可重复的错误，因此不会统计每天发生少于一次的位翻转错误。 几年前，我曾向 BTRFS 开发者报告台式电脑上的 BTRFS 损坏问题，其中一位开发者表示该损坏不符合任何预期的 BTRFS 错误模式，并建议我运行 Memtest86+。内存测试显示，大约每 5 小时出现一次内存损坏，因此如果我在该系统上使用 Firefox，任何崩溃可能都不会被视为 RAM 硬件错误。这些错误导致了文件系统损坏和一些数据丢失，如果我当时没有使用 BTRFS，这个问题可能多年都不会被发现。 另一次，我在一个虚拟机中测试自己开发的软件时，遇到了意外错误。我花了一天时间排查后，将错误共享给了一个邮件列表中的其他开发者，他们也都花了一些时间调查。最终我开始怀疑是硬件问题，我到达现场后重新启动系统以运行 Memtest86+，但系统甚至无法启动，因为错误导致 BIOS 都无法正常工作。奇怪的是，系统之前似乎工作正常，重启 KVM 虚拟机后，相同的错误在相同代码处再次出现，而虚拟机上的其他一切似乎都没有问题。结果发现是主板故障，导致除一个 DIMM 插槽外其余都无法使用，我最终将其送去了电子垃圾回收站。这浪费了我一天的时间和其他人几个小时的精力。可以推测，在其他情况下，开发时间也因硬件错误而浪费，但无人意识到这一点。 ## 社会所需 我们需要更广泛地使用 ECC RAM。理想情况下，政府应采取行动强制推行，因为 RAM 硬件错误导致数据损坏和浪费时间对社会造成持续损失。我认为至少需要对非 ECC RAM（以及 DDR5 的 EC4 RAM）征收足够高的税，使其新购价格比 ECC RAM 更贵。 计算机专家需要更深入地了解 ECC RAM 的优势，人们应建议在可能的情况下购买配备 ECC RAM 的计算机，并指出无法使用 ECC RAM 的系统（笔记本电脑和手机）不应存储重要数据。 我们需要避免诸如 RAM 变体过多、使人们困惑并让 ECC RAM 正常工作变得不必要地困难等愚蠢行为。 - [1]https://en.wikipedia.org/wiki/Hamming_code - [2]https://en.wikipedia.org/wiki/Registered_memory - [3]https://en.wikipedia.org/wiki/Chipkill - [4]https://www.atpinc.com/tw/blog/ddr5-what-is-on-die-ecc-how-is-it-different-to-traditional-ecc - [5]https://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf - [6]https://en.wikipedia.org/wiki/DDR5_SDRAM#Subchannels - [7]https://www.tomshardware.com/pc-components/ram/bit-flips-cause-up-to-15-percent-of-firefox-crashes-asserts-mozilla-engineer-figure-inferred-from-470-000-auto-submitted-crash-reports