http://www.nersc.gov/users/computational-systems/edison/configuration 에서 4 시간 동안 100k 코어에서 슈퍼 컴퓨터 계산을 실행 하여 네트워크를 통해 약 4PB의 데이터를 교환하고 약 4TB의 I / 영형. 계산은 모두 정수이므로 결과가 정확하거나 잘못되었습니다 (중간 수치 오류 없음).
코드가 정확하다고 가정하면 하드웨어 오류로 인해 계산이 잘못 될 가능성을 추정하고 싶습니다. 이것에 대해 좋은 방법은 무엇입니까? 그러한 견적을 내리는 데 필요한 수의 좋은 출처가 있습니까?
답변:
다양한 엑사 스케일 보고서가 나왔습니까? 어려운 실패는 오늘날 큰 문제가되지 않습니다. 물론, 그 빈도는 높지 않아 심각한 걱정을 일으킬 수 있습니다. 그러나 코드가 적절하게 반응하도록 준비해야하는 코어가 이상인 엑사 스케일 시스템에서는 충분히 빈번한 것으로 추정됩니다 . 이러한 문제는 엑사 스케일에 대한 로드맵 보고서에 제시되어 있다고 생각합니다.
다양한 장애 모드 중에서 메모리 또는 프로세서 코어의 단일 비트 플립이 가장 큰 문제는 아니라는 점을 기억합니다. 오히려 디스크 고장, 운영 체제 장애 등으로 인해 전체 노드가 다운되고있었습니다. 따라서 현재의 엑사 스케일 디자인은 플래시 RAM으로 코드의주기적인 체크 포인트를 요구하며, 바람직하게는 체크 포인트 데이터를 노드 외부로 전송합니다. 시스템에서 한 노드가 사라진 경우 코드를 이전에 저장된 상태에서 즉시 다시 시작할 수 있어야합니다.이 노드를 시스템의 다른 곳에서 핫 스타트 노드로 바꿉니다.
나는 당신이 DRAM과 같은 구성 요소의 오류율을 수집하는 것으로 시작한다고 생각 합니다.이 야생에서의 DRAM 오류에 대한 Google의 연구 : 대규모 현장 연구 매년 1 %의 수정 불가능한 오류가 발생할 확률을 발견했습니다.
그것이 당신이 관심있는 것인지 확실하지 않습니다. 감지 할 수없는 오류에 더 관심이 있습니다. 일반적인 오류 검사 방법으로 감지 할 수없는 오류 예를 들어, 광학 장치를 통해 패킷을 전송할 때 일종의 CRC가 수반되므로 오류가 발생할 가능성이 적습니다.
업데이트 :이 백서 멀티 코어 프로세서의 온라인 오류 감지 및 복구를위한 아키텍처는 신뢰할 수있는 멀티 코어 아키텍처에 대해 설명하지만 시스템 안정성의 여러 측면을 다루며 참고 문헌이 있습니다.
그러한 견적을 내리는 데 필요한 수의 좋은 출처가 있습니까?
컴퓨팅중인 클러스터의 관리자에게 문의하십시오. 검증 프로세스의 일부로 하드웨어 오류 가능성을 추정하는 문제에 직면했다고 생각합니다.
장대 한 소리. 이 실험을 수행 한 사람이 없으면 sha1 입력을 계속해서 다시 해싱하여 오류율이 무엇인지 확인하는 등 100k 개별 코어를 실행하는 것을 고려할 수 있습니다. (불확실한 것 같아) 의심 할 여지없이 네트워크 오류율을 얻기 위해 해시 체인 결과를 너무 자주 거래하도록하십시오. 이것은 또한 매우 작지만 몇 시간 동안 수퍼 클러스터를 사용하여 적어도 몇 명을 얻을 수 있다고 생각합니다. :)
이 접근 방식은 해싱이 단일 비트 스왑에 매우 민감하기 때문에 모든 계산이 올바른지 확인하는 반면 정수만 계산하더라도 분기에서 오류를 숨길 수 있습니다. 즉, 전체 계산이 각 연속 메모리 상태에서 타원이 아니어야합니다.
나는 가짜 결과를 제출하여 속임수를 쓰는 외부 클러스터에 의해 코드가 올바르게 실행되도록하는 방법을 연구했습니다. 내가 수렴 한 솔루션은 해시를 계산에 통합하여 업무 수행보다 부정 행위를 덜 효율적으로 만듭니다.