기본적으로 CPU는 오류 검사를 수행하거나 오류 수정 정보를 추가하도록 설계되지 않았기 때문에 의미 있는 방식으로 메모리 오류를 수정하려면 하드웨어 지원이 필요합니다. 소프트웨어는 RAM에서 읽은 데이터가 정확하다고 가정합니다.

소프트웨어가 RAM에서 값을 읽으면 일부 "로드" 명령을 통해 메모리에서 특정 위치를 가져오고 싶다고 CPU에 알립니다. (이것은 ZFS에서 데이터를 읽을 때 발생하는 것과 매우 다릅니다)

운영 체제나 기타 소프트웨어로서 수정되지 않은 소프트웨어의 읽기를 가로챌 가능성은 거의 없습니다.모든사용자 모드 읽기가 실패한 다음 메모리에서 해당 페이지를 로드하고 오류 검사를 수행한 후 마지막으로 값을 반환합니다. 매번 가상 메모리 주소를 선형 메모리 주소로 변환하는 조회 테이블을 포기하고 모든 캐시를 무효화합니다. 그렇지 않으면 시스템의 4kB 페이지마다 정확히 한 번씩 작동합니다. 결과적으로 귀하의 시스템은 매우 느려질 것입니다. 여기서는 Pentium 1에 대해 이야기하고 있습니다. 왜냐하면 대부분의 속도 이점은 이를 수행하지 않음에서 비롯되기 때문입니다. 오류 검사 메모리가 있는 매우 느린 시스템을 원한다면 ECC RAM이 있는 오래된 서버 하드웨어에 대한 많은 비용을 절약할 수 있는 하드웨어 재활용 업체가 있을 것이라고 확신합니다!

SoftECC 문서에서는 실제 문제에 대해 실제로 작동하지 않는 솔루션을 제안합니다. "오래된 메모리 페이지 확인"을 구현해야 합니다(자주 작성되는 페이지를 보호하지 못하지만 근접 효과로 인해 실제로 이러한 페이지는 보호되지 않음). 보호된 시스템이 필요하지만(Linux의 Row Hammer 참조)(현대 시스템에서는 행운을 빕니다) 여전히 엄청난 성능 저하를 경험하게 될 것입니다.

이제 무결성 검사 자체를 포함하도록 소프트웨어를 실제로 수정하려고 생각하고 있다면 이것이 가능합니다. 예를 들어 실제로 RAM에 대용량 데이터 캐시가 있는 데이터베이스 서버를 작성한다고 가정해 보겠습니다. 체크섬과 수정 사항을 직접 쉽게 구현할 수 있습니다. 그러나 문제는 시스템에서 실행되는 모든 소프트웨어에 대한 일반적인 RAM 보호 방식이 아니라 애플리케이션별 개발 및 채널 인코딩 중 하나가 됩니다.

솔직히 말하면, ECC는 현세대 데스크톱 CPU에 내장되어 있고 많은 마더보드가 이를 지원하며 ECC RAM은 그다지 비싸지 않습니다. ECC가 필요한 경우 소프트웨어가 아닌 아키텍처 관점에서 ECC를 구현하기에 적합한 장소는 하드웨어입니다.