WEBVTT 00:00.120 --> 00:00.960 インストラクター：このレッスンでは､ 00:00.960 --> 00:05.040 エラー訂正コードとして知られるECCメモリーについてお話しします｡ 00:05.040 --> 00:10.020 しかし､ その前に､ メモリの観点からノンパリティとパリティの概念をカバーする必要がある｡ 00:10.020 --> 00:14.160 さて､ ノンパリティといえば､ これは単なる標準的なメモリである｡ 00:14.160 --> 00:16.200 エラーをチェックせず､ 00:16.200 --> 00:21.390 データを自由にメモリに入れたり取り出したりできる｡ 00:21.390 --> 00:23.910 ノンパリティは製造コストが非常に安く､ 00:23.910 --> 00:26.970 パリティ・メモリーよりも高速だ｡ 00:26.970 --> 00:28.800 一方､ パリティ・メモリは､ 00:28.800 --> 00:34.890 基本的なエラー・チェックを行い､ メモリ内容の信頼性と整合性を確保するために使用される｡ 00:34.890 --> 00:38.460 このため､ このメモリはノンパリティ・メモリよりも遅くなるが､ 00:38.460 --> 00:44.910 サーバーや特定のハイエンド・デスクトップ・ワークステーションに必要とされる信頼性を備えている｡ 00:44.910 --> 00:47.220 パリティ・チェック機能を持つメモリは､ 00:47.220 --> 00:49.320 データが正常かどうかを確認するために､ 00:49.320 --> 00:52.920 目に見えるものから基本的な計算を行うことができる｡ 00:52.920 --> 00:55.110 そして､ そのデータが良いものであれば､ それを使う｡ 00:55.110 --> 00:58.560 そうでない場合､ エラーは発生するが､ それを修正することはできない｡ 00:58.560 --> 01:02.460 エラーが発生しましたが､ 修正方法はわかりません｡ 01:02.460 --> 01:07.230 基本的に､ これは各バイトにパリティ・ビットを持たせることで機能する｡ 01:07.230 --> 01:13.860 つまり､ 8ビットの代わりに､ 8データビット＋パリティ用1ビットで9ビットになる｡ 01:13.860 --> 01:16.200 これで､ パリティ・ビットが適切なタイミングでセットされることになる｡ 01:16.200 --> 01:17.970 そして､ メモリから読み出すときに､ 01:17.970 --> 01:21.420 そのデータが最後にメモリに書き込まれたときからビットのどれかが変わったかどうかを計算し､ 01:21.420 --> 01:24.330 比較する｡ 01:24.330 --> 01:25.470 しかし､ このようなチェックは､ 01:25.470 --> 01:28.470 シングル・ビット・エラーの検出に限定される｡ 01:28.470 --> 01:35.550 なぜなら､ ビットは0か1しかないからだ｡ 01:35.550 --> 01:44.460 例えば､ 2進数で00000000と書かれた数字0を保存したとしよう｡ 01:44.460 --> 01:47.700 これらのビットをすべて足すと､ 8つの0が得られ､ 01:47.700 --> 01:50.400 パリティ・ビットは0となる｡ 01:50.400 --> 01:54.090 その数字をメモリから読み出そうとしたとき､ 01:54.090 --> 01:59.850 0が8つあることがわかった｡ 01:59.850 --> 02:00.720 さて､ 一方では､ 02:00.720 --> 02:07.200 私が00000001と書かれた数字の1を書き留めていたとしよう｡ 02:07.200 --> 02:10.470 これらの数字を足すと1になる｡ 02:10.470 --> 02:13.530 そして､ 私はそれを第9ビットのパリティ・ビットに入れる｡ 02:13.530 --> 02:17.133 こうすることで､ そこから読み取ると00000001が得られる｡ 02:19.560 --> 02:25.440 しかし､ もしそのデータをメモリに入れて数時間放置し､ 02:25.440 --> 02:42.510 誤って1が0に変わってしまったとしたら......今そのデータを読むと00000000となり､ それを足すと0となる｡ 02:42.510 --> 02:44.730 この8ビットのうち､ どれが変更されたのかはわからないが､ 02:44.730 --> 02:46.560 少なくとも1つは変更されている｡ 02:46.560 --> 02:52.260 一方､ 00000001の数字が01010001のように変更された場合､ 02:52.260 --> 03:01.590 メモリによって誤って0から1に変更されたビットが2つあることになる｡ 03:01.590 --> 03:08.940 パリティを見ると､ 奇数ならパリティビットは1になる｡ 03:08.940 --> 03:12.090 それを足して偶数になれば0になる｡ 03:12.090 --> 03:14.940 つまり､ パリティ・タイプの計算を使用している場合､ 03:14.940 --> 03:20.100 この内部で2ビットが変更されたとしてもエラーを検出することはできない｡ 03:20.100 --> 03:25.770 さて､ 良いニュースとしては､ ほとんどのエラーの約90％はシングル・ビット・タイプのエラーであり､ 03:25.770 --> 03:30.000 パリティ・チェックは通常､ ほとんどの状況で十分であるということだ｡ 03:30.000 --> 03:31.530 しかし､ 銀行でサーバーを運用するような場合は､ 03:31.530 --> 03:35.520 どんなエラーも悪いことになりかねない｡ 03:35.520 --> 03:37.890 そこで､ パリティよりも優れたものが必要になり､ 03:37.890 --> 03:40.650 ECCが登場するわけだ｡ 03:40.650 --> 03:43.830 ECCはError Correcting Codeの略である｡ 03:43.830 --> 03:48.390 誤り訂正符号は､ パリティを次のレベルに引き上げるタイプのメモリである｡ 03:48.390 --> 03:51.810 パリティのようにエラーを検出するだけでなく､ 03:51.810 --> 03:54.780 そのエラーを修正することもできる｡ 03:54.780 --> 03:57.300 ECCはパリティより少し遅く､ 03:57.300 --> 03:59.490 ノンパリティより遅い｡ 03:59.490 --> 04:00.990 ECCはエラーを検出し､ 04:00.990 --> 04:11.760 エラーを修正することができるため､ ECCを使用することでメモリから高い整合性と信頼性を得ることができる｡ 04:11.760 --> 04:15.570 一般的に､ ECCやエラー訂正コードが使われるのは､ 04:15.570 --> 04:25.230 追加コストがかかるため､ 本当にハイエンドのワークステーションやサーバーに限られる｡ 04:25.230 --> 04:26.340 さて､ ECCは実際に何が問題で､ 04:26.340 --> 04:30.990 どう修正すべきかをどのように判断するのだろうか？ 04:30.990 --> 04:35.700 そのためには､ バッファード・メモリやレジスタード・メモリと呼ばれるものを使う｡ 04:35.700 --> 04:37.980 バッファード・メモリやレジスタード・メモリには､ 04:37.980 --> 04:42.870 メモリとCPUやプロセッサーの間に位置する追加のハードウェアがある｡ 04:42.870 --> 04:44.850 このハードウェアはレジスタと呼ばれ､ 04:44.850 --> 04:48.720 CPUに送られる前のデータをバッファに格納する｡ 04:48.720 --> 04:56.910 この機能は､ 多くのシステム､ 特にサーバーのようにエラーが発生する可能性のあるメモリモジュールを多数搭載しているシステムの信頼性対策として使用されている｡ 04:56.910 --> 05:02.370 これらのシステムでは､ 大容量のメモリモジュールを搭載したシステムで使用される電気的負荷を軽減するために､ 05:02.370 --> 05:04.680 データのバッファリングや登録が必要となる｡ 05:04.680 --> 05:08.220 また､ パリティやエラー訂正コード・メモリと組み合わせることで､ 05:08.220 --> 05:13.020 さらなる信頼性を確保し､ エラーを検出することができる｡ 05:13.020 --> 05:18.840 エラー訂正コードモジュールを使用するには､ CPUだけでなくマザーボードも対応していなければならない｡ 05:18.840 --> 05:21.450 これらのコンポーネントのいずれかがECCをサポートしていない場合､ 05:21.450 --> 05:27.150 より高価なECCモジュールを購入しても､ ECCの恩恵を受けることはできません｡ 05:27.150 --> 05:28.800 だから､ そのことを覚えておいてほしい｡ 05:28.800 --> 05:32.700 また､ ほとんどのマザーボードはECCをサポートしているか､ していないかのどちらかだ｡ 05:32.700 --> 05:34.140 一般的には選択肢に入らない｡ 05:34.140 --> 05:36.690 つまり､ ECCをサポートするマザーボードを購入するのであれば､ 05:36.690 --> 05:41.490 ECCモジュールを購入しなければならない｡ 05:41.490 --> 05:46.170 ECCまたは非ECCモジュールをサポートするマザーボードを見つけたとしても､ 05:46.170 --> 05:49.110 一般的には両方を同時にサポートすることはない｡ 05:49.110 --> 05:51.570 つまり､ すべてのモジュールがECCでなければならないか､ 05:51.570 --> 05:53.880 どのモジュールもECCであってはならないのだ｡ 05:53.880 --> 05:58.950 それらが混在していると､ システムにエラーが発生し､ マザーボードがそれをどう処理すればいいのかわからなくなる｡ 05:58.950 --> 06:00.210 さて､ 最後に触れておきたいのは､ 06:00.210 --> 06:06.780 DDR5を使用している場合､ DDR5にはモジュール自体に内部エラーチェック機能があるということだ｡ 06:06.780 --> 06:10.500 これはECCやECCモジュールとはみなされない｡ 06:10.500 --> 06:11.850 そのため､ 新しいDDR5モジュール内のこのエラー訂正は､ 06:11.850 --> 06:19.710 ECCをサポートしていないマザーボードでも使用でき､ エラーチェック機能は残っている｡ 06:19.710 --> 06:21.420 これはエラーチェックとは異なるもので､ 06:21.420 --> 06:23.910 エラー訂正コードとはみなされない｡ 06:23.910 --> 06:27.810 だから､ そのことを覚えておいて､ フィールドに出たときに混乱しないようにしてほしい｡ 06:27.810 --> 06:29.640 DDR5モジュールは､ 内部エラーチェックに加え､ 06:29.640 --> 06:32.040 CPUやマザーボードがECCをサポートしていれば､ 06:32.040 --> 06:44.040 そのCPUやマザーボードとも連動し､ エラー訂正コードも使用されるため､ ECCモジュールとしても非ECCモジュールとしても販売される｡ 06:44.040 --> 06:45.510 少し混乱するのは分かっている｡ 06:45.510 --> 06:48.210 だから､ フィールドに出るときはそのことを意識してほしい｡