ECCとDDR5

ECCとDDR5 2026年7月19日 2026年7月19日| etbeECCとDDR5| コメント0| 15:00 カテゴリ : Ha 目次 トグル ハムコード ECC RAMは、CPUに到達する前にメモリで発生するエラーを訂正します。ECCの最も一般的な形式はハムコード[1]であり、R個の冗長ビットを持つ場合、2^R-R-1ビットのデータメッセージで単一ビットエラーを訂正し、二重ビットエラーを検出できます。PC用途では、32ビットのデータを保護したい場合はR=6、64ビットの場合はR=7が必要です。DDR4および類似のRAMの標準は、バス上で72ビットのデータ幅であり、65ビットのデータに対して単一ビットエラーを訂正し、二重ビットエラーを検出するためのハムコードを使用しています。私たちが使用するコンピュータは64ビットのデータを持っているため、余分なパリティビットとして使用できる追加のビットがありますが、この追加ビットがどのように使用されているかは不明です。 RDIMM vs UDIMM このようなものにおける混乱の一点として、Registered memory（RDIMM）と、しばしばUDIMMと呼ばれる通常のPC/ラップトップメモリとの違いがあります。「レジスタ」は単なるバッファであり、この投稿には関連しない複雑な問題のために、DIMMをより大きくすることができ、システムに多くのDIMMを搭載できますが、レイテンシはわずかに悪化する可能性があります。ECCなしのRDIMM（72ビットではなく64ビット幅）を作成することは技術的に可能ですが、そのようなRAMを使用したシステムを見たことはありません。ECC UDIMMを使用したシステムはいくつかありますが、中古市場では高価であるため、可能であれば避けることをお勧めします。ECC RDIMMは非常に安価に入手できます。家庭用には不向きなECC RDIMMを搭載したサーバー（非常にうるさいデュアルCPU 1RUサーバーなど）がいくつかありますが、5年間の減価償却期間を過ぎるとサーバーシャーシはe-wasteに送られ、RAMは中古市場に出回ります。システムがない状態でのRAMの過剰供給は価格を下落させます。最も一般的に見られるシステムでは、ECC搭載のRDIMMシステムとECCなしのUDIMMシステムがあります。 Chipkill RAMの各ビットが他のビットと独立している場合、基本的なハムコードはほとんどの問題を解決するでしょう。しかし、同じチップ内の複数のビットが同じ問題の影響を受ける可能性があり、またはDIMM上の1つのチップが完全に故障する可能性があります。各RDIMMには18または36個のDRAMチップがあり、チップあたり2または4ビットです。36個のDRAMチップを持つDIMMでは、ハムコードでエラーを確実に検出できる1つのチップの故障が発生する可能性があります。18個のDRAMチップを持つDIMMでは、ハムコードで必ずしも検出できない1つのチップの故障が発生する可能性があります。IBMは、単一のDRAMチップの故障に対処できるECCシステムに「ChipKill」という用語を商標登録しました[3]。これはDellおよびHPサーバーでは「Advanced ECC」と呼ばれ、偶数個のDIMMが必要です。もし「ChipKill」タイプのシステムに使用されているコーディング方法を知っている方がいれば、教えてください。高度なECCを備えたシステムには、RAMのホットスペアやRAID-1タイプの機能もよくありますが、私のブログを読むほとんどの人が望むものではありません。 DDR5 DDR5は、より小さく高速なメモリ[4]からのエラー発生率の増加に対処するために、オンダイECCを備えています。これは、128ビットのデータあたり8ビットのエラー訂正として指定されており、基本的なハムコードを示唆しています。オンダイECCは通常のECCの代替ではなく、導入された新しい問題への緩和策です。メモリエラーに関する私の経験では、再現可能なエラー（システムがMemtest86+でエラーを発生させるか、ECCエラーレポートが繰り返し発生する）の大部分はDIMMの装着問題でした。問題のDIMMを抜き差しすると、同じテストがパスしました。これらのエラーはオンダイECCの影響を受けないでしょう。私が懸念しているのは、オンダイECCがマザーボード上のECCと相互作用して、その有効性を低下させる可能性です。これがどのように機能するかについては十分な情報を得られていないため、その可能性を判断できません。私の懸念は、基本的なハムコードで訂正される3ビット以上のエラーが、「Advanced ECC」が修正できないエラー条件を、元のエラーよりも多く作成する可能性があるということです。現在、RAMエラーに対するECCの有効性に関する最も優れた公開研究は、2009年に公開されたGoogleの論文であり、DDRおよびDDR2 RAM[5]に基づいています。そのため、DDR4 ECCに関する公開研究がすぐに目にされるとは予想していません。Googleや他のクラウドプロバイダーは依然としてそのような研究を行っており、DRAMベンダーにNDAの下で情報を提供していると推測されるため、DRAMベンダーが正しく機能するように必要なことを行い、その研究に基づいた製品を購入できるようにすることを願うしかありません。 DDR5 EC4 vs EC8 DDR5は、64ビットワードだけでなく、2つの32ビット「サブチャネル」をサポートしています[6]。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は私が何度か使用したことがありますが、ほとんどの人が見たことがないという状況を反映しているようです。次に、どのサーバーがサポートしているかについての情報を検索しました。Dell R760サーバーはEC4およびEC8 RDIMMの両方をサポートしていますが、同じシステムに両方を搭載することはできません。EC4 DIMMの存在は間違っています。彼らは標準以下の製品を作るべきではありません。72ビットと80ビット幅のDIMMの製造価格差はそれほど大きくなく、結果として一部のシステムは不十分な仕様になり、互換性のためにチェックするものが増えることでシステムのアップグレードが困難になります。 なぜECCが必要なのか MozillaがFirefoxのクラッシュの15％がRAMハードウェアエラーに起因すると主張している[7]という興味深い記事があります。これは再現可能なエラーに基づいているようで、1日に1回以下のビットフリップが発生するエラーはカウントされないでしょう。数年前、私はデスクトップPCでBTRFSの破損問題をBTRFS開発者に報告し、そのうちの1人が、その破損はBTRFSのバグから予想されるパターンとは一致しないと述べ、Memtest86+を実行するように勧めました。メモリテストでは、約5時間に1回メモリ破損が発生していることが明らかになりました。もしそのシステムでFirefoxを使用していたら、クラッシュはおそらくRAMのハードウェアエラーとは見なされなかったでしょう。それらのエラーはファイルシステムの破損と一部のデータ損失を引き起こしましたが、もしBTRFSを使用していなかったら、何年も気づかれなかったかもしれません。別の機会に、開発中のソフトウェアをテストするために使用していたVMで予期しないエラーが発生しました。1日作業した後、他の開発者のメーリングリストでエラーを共有し、彼らも調査に時間を費やしました。最終的にハードウェアの問題を疑い始め、現場に行き、システムを再起動してMemtest86+を実行しようとしたところ、BIOSさえ正しく起動しないエラーが発生していたため、起動すらできませんでした。システムは正常に動作しているように見え、KVM VMを再起動すると同じコードで同じエラーが発生し、VMの他の部分には問題がないように見えたのは奇妙でした。結局、システムのマザーボードの問題でDIMMソケットの1つしか使用できなくなり、e-wasteに送ることになりました。これは私の時間を1日、他の人々の時間を数時間無駄にしました。おそらく他の機会にも、ハードウェアエラーのために開発者の時間が無駄になり、誰もそれに気づいていないのでしょう。 社会が必要としているもの ECC RAMがより広く使用される必要があります。