Cosmic Rays : 프로그램에 영향을 미칠 확률은 얼마입니까?

다시 한 번 디자인 검토를 받았으며 특정 시나리오의 확률이 프로그램에 영향을 미치는 "우주선의 위험보다 적다"는 주장에 부딪 혔으며, 그 아이디어에 대해 가장 잘 모르는 아이디어가 나에게 생겼습니다. 확률은

이 때문에 " ^-128이 340282366920938463463374607431768211456 1 아웃, 나는 이러한 계산은 더에 우주선의 위험 억 몇 ... 우린 방식의 요인에 의해 떨어져있는 경우에도, 여기에 우리의 기회를 복용 우린 정당화 생각 우리를 망쳐 놓아 라. "

이 프로그래머가 맞습니까? 우주 광선이 컴퓨터를 때리고 프로그램 실행에 영향을 미칠 확률은 얼마입니까?

에서 위키 백과 :

1990 년대 IBM의 연구에 따르면 컴퓨터는 일반적으로 한 달에 256MB의 RAM 당 하나의 우주 광선 유발 오류를 경험합니다. ^[15]

이는 매월 바이트 당 3.7 × 10 ^-9 또는 초당 바이트 당 1.4 × 10 ^-15 의 확률을 의미합니다 . 프로그램이 1 분 동안 실행되고 20MB의 RAM을 차지하는 경우 실패 확률은 다음과 같습니다.

                 60 × 20 × 1024²
1 - (1 - 1.4e-15)                = 1.8e-6 a.k.a. "5 nines"

오류 점검은 실패의 여파를 줄이는 데 도움이 될 수 있습니다. 또한 Joe가 언급 한 칩 크기가 더 작기 때문에 고장률은 20 년 전과 다를 수 있습니다.

분명히 중요하지 않습니다. 에서 이 뉴 사이언티스트 기사 , 인텔 특허 출원에서 인용 :

"우주선에 의한 컴퓨터 충돌은 발생했으며, 디바이스 (예를 들어, 트랜지스터)의 칩 크기가 감소함에 따라 주파수에 따라 증가 할 것으로 예상됩니다.이 문제는 향후 10 년 동안 컴퓨터 신뢰성의 주요 제한자가 될 것으로 예상됩니다."

여기 에서 전체 특허를 읽을 수 있습니다 .

참고 : 이 답변은 물리학이 아니라 비 ECC 메모리 모듈의 자동 메모리 오류에 관한 것입니다. 일부 오류는 외부 공간에서, 일부는 데스크톱의 내부 공간에서 발생할 수 있습니다.

CERN 클러스터 및 Google 데이터 센터와 같은 대규모 서버 팜에서 ECC 메모리 오류에 대한 여러 연구가 있습니다. ECC가있는 서버급 하드웨어는 모든 단일 비트 오류를 ​​감지하고 수정할 수 있으며 많은 다중 비트 오류를 ​​감지 할 수 있습니다.

비 ECC 데스크톱 (및 비 ECC 모바일 스마트 폰)이 많다고 가정 할 수 있습니다. ECC로 수정 가능한 오류율 (단일 비트 플립)에 대해 논문을 확인하면 비 ECC 메모리에서 자동 메모리 손상 률을 알 수 있습니다.

• 대규모 CERN 2007 연구 "데이터 무결성" : 공급 업체는 "선언 (10)의 비트 오류율 ^-12 자신의 메모리 모듈 ", " 관찰 오류율 크기의 4 개 주문이 예상보다 낮은 것입니다 ". 데이터 집약적 인 작업 (8GB / s의 메모리 읽기)의 경우 이는 1 분마다 ( ^10-12 벤더 BER) 또는 2 일에 한 번 ( ^10-16 BER) 단일 비트 플립이 발생할 수 있음을 의미합니다 .

• 2009 구글의 논문 "와일드에서의 DRAM 오류 : 대규모 현장 연구"에 따르면 Mbit 당 최대 25000-75000 개의 1 비트 FIT ( 10 억 시간당 실패 )가 1-5 비트에 해당한다고합니다. 내 계산 후 8GB RAM에 대한 시간당 오류. 종이도 마찬가지다. " 연간 GB 당 2000–6000의 수정 가능한 오류율을 의미한다 ".

• 2012 Sandia 보고서 "대규모 고성능 컴퓨팅을위한 자동 데이터 손상 탐지 및 수정" : "더블 비트 플립은 거의 불가능한 것으로 간주됩니다." ECC와 함께. 그리고 단일 비트 오류가 더 높아야합니다.

따라서 프로그램에 큰 데이터 세트 (수 GB)가 있거나 메모리 읽기 또는 쓰기 속도 (GB / s 이상)가 높고 몇 시간 동안 실행되는 경우 데스크톱 하드웨어에서 최대 몇 개의 자동 비트 플립을 기대할 수 있습니다. 이 속도는 memtest로 감지 할 수 없으며 DRAM 모듈이 좋습니다.

BOINC 인터넷 전체 그리드 컴퓨팅과 같은 수천 개의 비 ECC PC에서 긴 클러스터를 실행하면 항상 메모리 비트 충돌 및 디스크 및 네트워크 자동 오류로 인한 오류가 발생합니다.

Sandia의 2012 보고서에서 볼 수 있듯이 단일 비트 오류로부터 ECC를 보호하는 경우에도 더 큰 시스템 (1 만 대의 서버)의 경우 매일 이중 비트 플립이 발생할 수 있으므로 전체 크기 병렬을 실행할 수있는 기회가 없습니다 며칠 동안 프로그램 (정기 검사 점 및 이중 오류의 경우 마지막 검사 점에서 다시 시작하지 않음). ECC에 의해 보호되는 것은 아니기 때문에 거대한 머신은 캐시 및 CPU 레지스터 (ALU 데이터 경로 등의 아키텍처 및 내부 칩 트리거 모두)에서 비트 플랩을 얻을 수 있습니다.

추신 : DRAM 모듈이 불량하면 상황이 훨씬 나빠질 것입니다. 예를 들어 노트북에 새로운 DRAM을 설치했는데 몇 주 후에 사망했습니다. 많은 메모리 오류가 발생하기 시작했습니다. 내가 얻는 것 : 랩톱이 멈추고, 리눅스가 재부팅되고, fsck가 실행되고, 루트 파일 시스템에서 오류를 발견하고 오류를 수정 한 후 재부팅하고 싶다고 말합니다. 그러나 매번 재부팅 할 때마다 (약 5-6 번 정도) 루트 파일 시스템에 여전히 오류가 있습니다.

Wikipedia 는 90 년대 IBM 의 연구에 따르면 "컴퓨터는 일반적으로 한 달에 256MB의 RAM 당 하나의 우주 광선 유발 오류에 대해 경험하고 있습니다"라고 말합니다. 불행히도 인용은 Scientific American의 기사에 관한 것으로, 더 이상 언급하지 않았습니다. 개인적으로 그 숫자는 매우 높지만 우주 광선에 의해 유발되는 대부분의 메모리 오류는 실제로 또는 눈에 띄는 문제를 일으키지 않습니다.

반면에 소프트웨어 시나리오와 관련하여 확률에 대해 이야기하는 사람들은 일반적으로 그들이 말하는 것에 대한 단서가 없습니다.

글쎄, 우주 광선은 분명히 도요타 자동차의 전자 장치가 오작동을 일으켰으므로 확률이 매우 높다고 말합니다. :)

우주 광선이 실제로 도요타를 화나게 하는가?

ECC를 사용하면 Cosmic Rays의 1 비트 오류를 ​​수정할 수 있습니다. 우주 광선으로 인해 2 비트 오류가 발생하는 경우의 10 %를 피하기 위해 ECC 셀은 일반적으로 칩 위에 인터리브되므로 두 셀이 서로 인접하지 않습니다. 따라서 두 셀에 영향을 미치는 우주 광선 이벤트는 두 개의 수정 가능한 1 비트 오류를 ​​발생시킵니다.

태양 상태 : (2002 년 4 월 부품 번호 816-5053-10)

일반적으로 우주 광선 소프트 오류는 DRAM 메모리에서 ~ 10 ~ 100 FIT / MB의 속도로 발생합니다 (1 FIT = 1 개의 장치가 10 억 시간 내에 실패 함). 따라서 10GB의 메모리가있는 시스템은 1,000 ~ 10,000 시간마다 ECC 이벤트를 표시해야하며 100GB의 시스템은 100 ~ 1,000 시간마다 이벤트를 표시해야합니다. 그러나 이것은 대략적인 추정치이며 위에서 설명한 효과의 함수로 변경 될 것입니다.

메모리 오류는 실제로 발생하며 ECC 메모리가 도움이됩니다. 올바르게 구현 된 ECC 메모리는 단일 비트 오류를 ​​수정하고 이중 비트 오류를 ​​감지합니다 (이러한 오류가 감지되면 시스템이 정지됨). 사람들이 Memtest86 및 불량 메모리 발견. 물론 우주 광선으로 인한 일시적 오류는 지속적으로 실패하는 메모리 조각과 다르지만 메모리가 올바르게 작동하기 위해 얼마나 신뢰해야하는지에 대한 광범위한 질문과 관련이 있습니다.

상주 크기가 20MB 인 분석은 사소한 응용 프로그램에 적합 할 수 있지만 대규모 시스템에는 일반적으로 주 메모리가 큰 여러 서버가 있습니다.

흥미로운 링크 : http://cr.yp.to/hardware/ecc.html

불행히도 페이지의 해적 링크는 죽은 것 같습니다.

이것은 실제 문제이므로 ECC 메모리가 서버 및 임베디드 시스템에 사용됩니다. 그리고 비행 시스템이 지상 시스템과 다른 이유는 무엇입니까?

예를 들어 "내장 된"응용 프로그램을 대상으로하는 인텔 부품은 사양 시트에 ECC를 추가하는 경향이 있습니다. 태블릿의 베이 트레일에는 메모리가 조금 비싸고 느려질 수 있기 때문에 부족합니다. 그리고 태블릿이 푸른 달에 한 번 프로그램에 충돌을 일으키는 경우 사용자는별로 신경 쓰지 않습니다. 어쨌든 소프트웨어 자체는 HW보다 훨씬 덜 안정적입니다. 그러나 산업 기계 및 자동차 용 SKU의 경우 ECC는 필수입니다. 여기에서 SW는 훨씬 더 안정적 일 것으로 예상되며 임의의 혼란으로 인한 오류가 실제로 문제가 될 것입니다.

IEC 61508 및 이와 유사한 표준으로 인증 된 시스템에는 일반적으로 모든 RAM이 작동하는지 (0 또는 1에 비트가 멈춤 없음) 확인하는 부팅 테스트와 ECC에서 감지 된 오류를 복구하려고하는 런타임시 오류 처리가 있습니다. 종종 발생하는 모든 오류가 눈에 띄도록 메모리를 지속적으로 읽고 쓰는 메모리 스크러버 작업도 있습니다.

그러나 주류 PC 소프트웨어의 경우? 별거 아니야 오래 지속되는 서버? ECC 및 결함 핸들러를 사용하십시오. 수정할 수없는 오류로 인해 커널이 종료되면 커져야합니다. 또는 하나의 코어가 손상되면 첫 번째 코어가 재부팅되는 동안 다른 코어가 대신 할 수 있도록 편집 단계를 수행하고 잠금 단계 실행이있는 중복 시스템을 사용합니다.

프로그램이 생명에 중요한 경우 (실패하면 누군가를 죽일 수 있음), 안전을 보장하거나 이러한 실패로부터 자동으로 복구되는 방식으로 작성해야합니다. 다른 모든 프로그램, YMMV.

도요타가 그 예입니다. 스로틀 케이블에 대해 무엇을할지 말하지만 소프트웨어 는 아닙니다 .

http://en.wikipedia.org/wiki/Therac-25 참조

한 번 우주에서 날아 다니는 장치를 프로그래밍 한 후, 당신은 (어쩌면 아무도 그것에 대해 어떤 종이도 보여주지 않았지만, 사업 상 일반적인 지식이라고 말했지만) 항상 광선이 오류를 유발할 것으로 기대할 수있었습니다.

"우주 광선 사건"은 여기에 많은 답변에서 균일 한 분포를 갖는 것으로 간주되며, 이것이 항상 사실이 아닐 수도 있습니다 (즉, 초신성). (위키 백과에 따른 적어도)에서 유래 정의에 의해 "우주선"하지만 외부 공간, 나는 또한에 그것의 공정을 포함 생각하는 지역 태양 폭풍 (일명 코로나 질량 방출 같은 우산 아래. 나는 그것이 내 플립 여러 비트를 일으킬 수 있으리라 생각합니다 ECC 가능 메모리까지 손상시키기에 충분한 시간.

1989 년 3 월 의 퀘벡 정전 과 같이 전기 폭풍으로 인해 태양 폭풍이 상당히 큰 혼란을 야기 할 수 있다는 것은 잘 알려져 있습니다. 입니다. 컴퓨터 시스템에도 영향을 줄 수 있습니다.

약 10 년 전 나는 다른 사람 옆에 앉아 있었고, 우리는 각각의 노트북과 함께 앉아있었습니다. 그것은 꽤 "폭풍이 짙은"태양 날씨가있는시기였습니다 (북극에 앉아, 우리는 이것을 간접적으로 볼 수있었습니다- 볼 수 있습니다). 갑자기 같은 순간에 두 랩톱 모두 충돌했습니다. 그는 OS X를 실행 중이고 Linux를 실행 중이었습니다. 우리 둘 다 랩톱 충돌에 익숙하지 않습니다-Linux 및 OS X에서는 매우 드문 일입니다. 다른 OS에서 실행 중이기 때문에 일반적인 소프트웨어 버그는 거의 배제 될 수 있습니다 (그리고 도약 중에는 발생하지 않았습니다) 둘째). 나는 그 사건을 "우주 방사선"에 기인한다고 생각했다.

나중에 "우주 방사선"은 제 직장에서 내부 농담이되었습니다. 서버에서 어떤 일이 발생하여 이에 대한 설명을 찾을 수 없을 때마다, 우리는 농담으로 결함을 "우주 방사선"으로 간주합니다. :-)

더 자주 노이즈가 데이터를 손상시킬 수 있습니다. 체크섬 은 여러 수준에서이를 방지하는 데 사용됩니다. 데이터 케이블에는 일반적으로 데이터와 함께 이동 하는 패리티 비트 가 있습니다. 이것은 크게 하면 손상 가능성 줄어 듭니다. 그런 다음 파싱 수준에서 넌센스 데이터는 일반적으로 무시되므로 일부 손상이 패리티 비트나 다른 체크섬을 지나쳐도 대부분의 경우 무시됩니다.

또한 일부 구성 요소는 노이즈를 차단하기 위해 전기적으로 차폐 되어 있습니다 (아마도 우주 광선이 아닌 것 같습니다).

그러나 결국 다른 응답자들이 말했듯이 때때로 스크램블링되는 비트 또는 바이트가 있으며 이것이 중요한 바이트인지 아닌지에 대한 가능성이 있습니다. 가장 좋은 시나리오는 우주 광선이 빈 비트 중 하나를 스크램블하고 전혀 영향을 미치지 않거나 컴퓨터를 충돌시키는 것입니다 (컴퓨터가 해를 입지 않기 때문에 좋은 일입니다). 하지만 최악의 경우는 상상할 수있을 것입니다.

나는 이것을 경험했습니다-우주 광선이 1 비트 뒤집히는 것은 드문 일이 아니지만 사람이 이것을 관찰 할 가능성은 거의 없습니다.

2004 년에 설치 프로그램의 압축 도구를 사용하고있었습니다. 테스트 데이터는 약 500MB 이상의 일부 Adobe 설치 파일이었습니다.

지루한 압축 실행과 무결성 테스트를위한 압축 해제 실행 후 FC / B는 1 바이트가 다르게 나타났습니다.

그 1 바이트 내에서 MSB는 뒤집 혔습니다. 나는 또한 매우 특정한 조건에서만 표면에 나타날 미친 벌레가 생길까 걱정하면서 뒤집 었습니다.

그러나 무언가가 다시 테스트를 실행하라고 나에게 말했다. 나는 그것을 실행하고 통과했다. 밤새 테스트를 5 번 실행하는 스크립트를 설정했습니다. 아침에 5 명이 모두 지나갔습니다.

그것은 분명히 우주 광선 비트 플립이었습니다.

Fault Tolerant 하드웨어도 살펴볼 수 있습니다.

예를 들어 Stratus Technology는 계산 결과를 비교하여 잠금 단계에서 2 개 또는 3 개의 "메인 보드"를 가진 ftServer라는 Wintel 서버를 구축합니다. (이것은 때때로 우주 차량에서도 이루어집니다).

Stratus 서버는 맞춤형 칩셋에서 백플레인의 잠금 단계로 발전했습니다.

매우 유사한 (그러나 소프트웨어) 시스템은 하이퍼 바이저 기반 VMWare Fault Tolerance 잠금 단계입니다.

데이터 포인트로서 이것은 우리 빌드에서 발생했습니다.

02:13:00,465 WARN  - In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/ostream:133:
02:13:00,465 WARN  - /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/locale:3180:65: error: use of undeclared identifier '_'
02:13:00,465 WARN  - for (unsigned __i = 1; __i < __trailing_sign->size(); ++_^i, ++__b)
02:13:00,465 WARN  - ^
02:13:00,465 WARN  - /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/locale:3180:67: error: use of undeclared identifier 'i'
02:13:00,465 WARN  - for (unsigned __i = 1; __i < __trailing_sign->size(); ++_^i, ++__b)
02:13:00,465 WARN  - ^

컴파일 중에 소스 파일의 우연한 위치에서 비트 플립이 발생하는 것처럼 보입니다.

나는 이것이 반드시 "우주선"이라고 말하지는 않지만 증상이 일치합니다.