メモリはやっぱりECC Part5

1 ：Socket774：2013/03/06(水) 17:06:22.60 ID:iCahY9yh.net

過去すれ
メモリはやっぱりECC Part4
http://anago.2ch.net/test/read.cgi/jisaku/1305969862/
メモリはやっぱりECC Part3
http://hibari.2ch.net/test/read.cgi/jisaku/1283046765/
メモリはやっぱりECC Part2
http://hibari.2ch.net/test/read.cgi/jisaku/1261291017/
初代スレ
【Transcend】メモリはやっぱりECC【 SuperTalent】
http://pc11.2ch.net/test/read.cgi/jisaku/1227278105/

761 ：Socket774：2016/01/03(日) 16:48:26.98 ID:zpeLXjel.net

>>760
固定処理は電力効率の悪い汎用プロセッサがするべき仕事ではないだろ。

ハードで持つべきなのは明白だよ。

762 ：Socket774：2016/01/03(日) 17:02:28.79 ID:LLELYMUw.net

Intel CPUのメモリコントローラはECC非対応のi7なんかでも
単にdisableにされているだけで回路自体は持ってるわけで、
そのCPUでメインメモリECCをソフト処理とか、実にばかばかしい

763 ：Socket774：2016/01/03(日) 17:26:52.85 ID:LLELYMUw.net

CRC、ECC、パリティ等は機能ブロックのエラーを検知するためのものでDRAMから
遠く離れたCPUレジスタを使ってECCチェックというのはどうなのかな

SPARC64とか、CPU内部のあらゆる機能ブロックにそれぞれ
ECCやパリティが付いてる。

ttp://www.ssken.gr.jp/MAINSITE/download/newsletter/2006/sci/2/3_inouePPT.pdf#page=25
ttp://www.ssken.gr.jp/MAINSITE/download/newsletter/2006/sci/2/3_inoue.html

764 ：Socket774：2016/01/03(日) 19:47:50.68 ID:p5cqIe3E.net

>>763
最終的にはCPUがレジスタ情報を利用するわけで、結果オーライなんじゃね？
むしろメモリー側でeccチェックしたところで、伝送で化けたらいみなんだから

765 ：Socket774：2016/01/03(日) 20:26:42.89 ID:sadaK5Ij.net

伝送で化けたらECC自体が意味ないだろ。

766 ：Socket774：2016/01/03(日) 22:26:18.25 ID:ak/J/rph.net

eccはメモリコントローラーで計算されるから、
CPUに入るまではECCは意味がある。

767 ：Socket774：2016/01/04(月) 04:55:50.98 ID:O9bEAyDb.net

>>761
スマン。書き方がザックリだった。例えば64バイトを一度に読んで、そのうちう8バイトをエラー訂正用にさく。メモリの実質容量が減るが、そこらへんのありふれた
ECC非対応のメモリでも、エラー訂正ができることが利点。もちろん、ハード側で処理。

768 ：Socket774：2016/01/04(月) 05:06:42.23 ID:O9bEAyDb.net

改行位置間違えた。
ハード側とは、CPUのハードウェアで処理と言う意味。
可能なら、64+8バイト(72バイト)単位で読み書きのほうがいいかも。

769 ：Socket774：2016/01/04(月) 08:02:58.57 ID:pkqRKmYG.net

>>767
ANS-9010というDRAMストレージがそういう実装してたよ。
(ECC付きメモリも対応。)

>>768
メモコン側のECCはインテルが無効化してるので不可能っていうのは理解してるよね。
たとえハードウエアに紐付けされた拡張命令使っても、CPUで制御するのは普通はソフト処理って言うんじゃない？
72バイト幅アクセスは、アクセス先のチップが無いから不可能。

770 ：Socket774：2016/01/04(月) 08:06:30.86 ID:pkqRKmYG.net

>>767
UEFIとOSの対応が必要だし、その対価はどこも払わないから誰も対応しないよ。
素直にZEON+ECCメモリに行っとくべき。