Kozmik Işınlar: Bir programı etkileme olasılıkları nedir?

Bir kez daha bir tasarım incelemesine katıldım ve belirli bir senaryo olasılığının programı etkileyen "kozmik ışın riskinden daha az" olduğu iddiasıyla karşılaştım ve bunun en ince fikrine sahip olmadığım aklıma geldi olasılık.

"2 ^-128 , 340282366920938463463374607431768211456'dan 1 olduğu için, bu hesaplamalar birkaç milyarlık bir faktör tarafından kapatılsa bile, şansımızı burada almaya haklı olduğumuzu düşünüyorum ... bizi mahvediyorum, inanıyorum. "

Bu programcı doğru mu? Bir kozmik ışının bir bilgisayara çarpması ve programın yürütülmesini etkileme olasılığı nedir?

Gönderen Vikipedi :

1990'larda IBM tarafından yapılan çalışmalar, bilgisayarların ayda 256 megabayt RAM başına genellikle bir kozmik ışına bağlı hata yaşadığını göstermektedir. ^[15]

Bu, bayt başına ayda 3.7 × ^{10-9 veya} saniyede bayt başına 1.4 × ^10-15 olasılığı anlamına gelir . Programınız 1 dakika çalışır ve 20 MB RAM kaplarsa, hata olasılığı

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

Hata kontrolü, başarısızlığın sonrasındaki azalmaya yardımcı olabilir. Ayrıca, Joe tarafından yorumlandığı gibi daha kompakt cips boyutu nedeniyle, arıza oranı 20 yıl önce olduğundan farklı olabilir.

Görünüşe göre, önemsiz değil. Gönderen bu New Scientist makalesinde , Intel patent başvurusundan bir alıntı:

"Kozmik ışının neden olduğu bilgisayar çökmeleri meydana geldi ve aygıtların (örneğin, transistörler) yongalardaki boyutu azaldıkça frekansla artması bekleniyor. Bu sorunun önümüzdeki on yıl içinde bilgisayar güvenilirliğinin önemli bir sınırlayıcısı olması bekleniyor."

Patentin tamamını buradan okuyabilirsiniz .

Not: Bu cevap fizik değil, ECC olmayan bellek modüllerindeki sessiz bellek hataları ile ilgilidir. Bazı hatalar dış uzaydan, bazıları - masaüstünün iç uzayından gelebilir.

CERN kümeleri ve Google veri merkezleri gibi büyük sunucu çiftliklerinde ECC bellek hataları ile ilgili birkaç çalışma vardır. ECC'li sunucu sınıfı donanım, tüm tek bit hatalarını algılayabilir ve düzeltebilir ve birçok çok bitli hatayı algılayabilir.

ECC olmayan masaüstü bilgisayarların (ve ECC olmayan mobil akıllı telefonların) olduğunu varsayabiliriz. Makalelerde ECC ile düzeltilebilir hata oranları (tek bitflips) olup olmadığını kontrol edersek, ECC olmayan bellekte sessiz bellek bozulma oranını bilebiliriz.

• Büyük ölçekli CERN 2007 çalışması "Veri bütünlüğü" : satıcılar " bellek modülleri için ^10-12 Bit Hata Oranı ", " gözlenen bir hata oranı beklenenden 4 büyüklükte daha düşüktür " diyor. Veri yoğun görevler için (8 GB / sn bellek okuma) bu, her dakika ( ^10-12 satıcı BER) veya iki günde bir ( ^10-16 BER) tek bit çevirme olabileceği anlamına gelir .

• 2009 Google'ın kağıt "Wild DRAM hatalar: Bir Büyük Ölçekli Saha Çalışması" Mbit başına 25000-75000 tek bitlik uygun olduğunda (orada olabileceğini söylüyor milyar saatten başına sürede arızaları 1'e eşit olduğu), - 5 bitlik Hesaplamalarımdan sonra 8GB RAM için saatte hata. Paper aynı şeyi söylüyor: " GB başına yıllık 2000–6000 düzeltilebilir hata oranı ortalaması ".

• 2012 Sandia raporu "Büyük Ölçekli Yüksek Performanslı Hesaplama için Sessiz Veri Bozulması Tespiti ve Düzeltilmesi" : "çift bitli döndürmeler olası görülmedi" ancak ORNL'in yoğun Cray XT5'inde "75.000+ DIMM için günde bir kez" bile var ECC ile. Ve tek bit hataları daha yüksek olmalıdır.

Bu nedenle, program büyük veri kümesine (birkaç GB) veya yüksek bellek okuma veya yazma hızına (GB / s veya daha fazla) sahipse ve birkaç saat çalışırsa, masaüstü donanımında birkaç sessiz bit döndürmeyi bekleyebiliriz. Bu oran memtest tarafından tespit edilemez ve DRAM modülleri iyidir.

Uzun küme, BOINC internet çapında grid computing gibi binlerce ECC olmayan bilgisayarda çalışır, her zaman bellek bit çevirme ve ayrıca disk ve ağ sessiz hatalarından hatalar olacaktır.

Sandia'nın 2012 raporunda gördüğümüz gibi, tek bit hatalarından ECC korumasına sahip daha büyük makineler (10 bin sunucu) için, her gün çift bit döndürmeler olabilir, bu nedenle tam boyutlu paralel çalıştırma şansınız olmayacaktır. birkaç gün boyunca program (düzenli kontrol noktası olmadan ve çift hata durumunda son iyi kontrol noktasından yeniden başlatılmadan). Büyük makineler ayrıca önbelleklerinde ve cpu kayıtlarında (hem ALU veri yolunda hem mimari hem de dahili çipin tetikleyicileri) bit döndürürler, çünkü hepsi ECC tarafından korunmaz.

Not: DRAM modülü bozuksa işler çok daha kötü olacaktır. Örneğin, birkaç hafta sonra ölen dizüstü bilgisayara yeni DRAM taktım. Çok fazla bellek hatası vermeye başladı. Ne aldım: dizüstü bilgisayar kilitleniyor, linux yeniden başlatılıyor, fsck çalışıyor, kök dosya sisteminde hatalar buluyor ve hataları düzelttikten sonra yeniden başlatmak istediğini söylüyor. Ama bir sonraki her yeniden başlatmada (yaklaşık 5-6 tane yaptım) hala kök dosya sisteminde bulunan hatalar var.

Wikipedia 90'lı yıllarda IBM tarafından yapılan bir araştırmada "bilgisayarların ayda 256 megabayt RAM başına yaklaşık bir kozmik ışına bağlı hata yaşadığını" gösteriyor. Maalesef alıntı, Scientific American'da başka referans vermeyen bir makaleye yapıldı. Şahsen, bu sayının çok yüksek olduğunu düşünüyorum, ancak belki kozmik ışınların neden olduğu bellek hatalarının çoğu gerçek veya fark edilebilir sorunlara neden olmaz.

Öte yandan, yazılım senaryoları söz konusu olduğunda olasılıklar hakkında konuşan insanların tipik olarak ne hakkında konuştukları hakkında bir fikri yoktur.

Kozmik ışınlar görünüşe göre Toyota otomobillerindeki elektroniklerin arızalanmasına neden oldu, bu yüzden olasılığın çok yüksek olduğunu söyleyebilirim :)

Kozmik ışınlar gerçekten Toyota'nın sıkıntılarına neden oluyor mu?

ECC ile Kozmik Işınların 1 bit hatalarını düzeltebilirsiniz. Kozmik ışınların 2 bitlik hatalara yol açtığı vakaların% 10'undan kaçınmak için ECC hücreleri tipik olarak yongalar üzerinde serpiştirilir, böylece iki hücre yan yana olmaz. Bu nedenle, iki hücreyi etkileyen bir kozmik ışın olayı, iki düzeltilebilir 1 bit hatasına neden olur.

Güneş durumları: (Parça No. 816-5053-10 Nisan 2002)

Genel olarak konuşursak, DRAM belleğinde ~ 10 ila 100 FIT / MB oranında kozmik ışın yumuşak hataları meydana gelir (1 FIT = 1 cihaz 1 milyar saatte başarısız olur). Bu nedenle, 10 GB belleğe sahip bir sistem her 1000 ila 10.000 saatte bir ECC olayı göstermelidir ve 100 GB'a sahip bir sistem her 100 ila 1.000 saatte bir olay gösterecektir. Bununla birlikte, bu, yukarıda özetlenen etkilerin bir fonksiyonu olarak değişecek kaba bir tahmindir.

Bellek hataları gerçek ve ECC bellek yardımcı oluyor. Doğru uygulanan ECC bellek tek bit hataları düzeltmek ve çift bit hataları tespit edecek (örneğin bir hata tespit edildiğinde sistemin durdurulması.) İnsanların çalıştırılarak çözülen bir yazılım sorunu gibi görünüyor ne şikayet ne kadar düzenli gelen görebilirsiniz memtest86 ve kötü hafızayı keşfetmek. Elbette kozmik bir ışının neden olduğu geçici bir arıza, sürekli olarak başarısız olan bir bellek parçasından farklıdır, ancak belleğinizin doğru çalışması için ne kadar güvenmeniz gerektiğine dair daha geniş bir soru ile ilgilidir.

20 MB yerleşik büyüklüğüne dayanan bir analiz önemsiz uygulamalar için uygun olabilir, ancak büyük sistemler rutin olarak büyük ana belleklere sahip birden fazla sunucuya sahiptir.

İlginç bağlantı: http://cr.yp.to/hardware/ecc.html

Sayfadaki Corsair bağlantısı maalesef ölü gibi görünüyor.

Bu gerçek bir konudur ve bu nedenle ECC belleği sunucularda ve gömülü sistemlerde kullanılır. Ve uçan sistemler neden yer tabanlı sistemlerden farklıdır.

Örneğin, "katıştırılmış" uygulamalar için hedeflenen Intel parçalarının teknik özelliklere ECC ekleme eğiliminde olduğunu unutmayın. Bir tablet için bir Bay Trail, hafızayı biraz daha pahalı ve muhtemelen daha yavaş hale getireceğinden, eksiktir. Ve bir tablet mavi ayda bir programı çöktüğünde, kullanıcı çok fazla umursamaz. Yazılımın kendisi zaten HW'den çok daha az güvenilir. Ancak endüstriyel makine ve otomotivde kullanılmak üzere tasarlanan SKU'lar için ECC zorunludur. Buradan beri, SW'nin çok daha güvenilir olmasını bekliyoruz ve rastgele rahatsızlıklardan kaynaklanan hatalar gerçek bir sorun olacaktır.

IEC 61508 ve benzer standartlara göre sertifikalı sistemler genellikle hem tüm RAM'in işlevsel olup olmadığını kontrol eden önyükleme testlerine (sıfır veya birde takılı bit yok) hem de ECC tarafından tespit edilen hatalardan kurtulmaya çalışan çalışma zamanında hata işleme ve Ayrıca, meydana gelen hataların fark edildiğinden emin olmak için sürekli olarak bellek okuma ve yazma ve bellek yazma görevlerini de yerine getirir.

Ama genel PC yazılımı için? Önemli bir şey değil. Uzun ömürlü bir sunucu için mi? ECC ve bir hata giderici kullanın. Düzeltilemez bir hata çekirdeği öldürürse, öyle olsun. Ya da paranoyaklaşırsınız ve bir adım bozulursa, diğer çekirdek ilk çekirdek yeniden başlatılırken diğerini devralabilir.

Bir program yaşam için kritik öneme sahipse (başarısız olursa birini öldürür), ya arıza korumalı olacak ya da bu tür bir arızadan otomatik olarak kurtulacak şekilde yazılmalıdır. Diğer tüm programlar, YMMV.

Toyotalar buna bir örnektir. Bir gaz kablosu hakkında ne söyleyeceğinizi söyleyin, ancak yazılım değildir .

Ayrıca bkz http://en.wikipedia.org/wiki/Therac-25

Bir zamanlar uzayda uçacak cihazları programladım ve sonra (sözde, hiç kimse bana bu konuda herhangi bir kağıt göstermedi, ancak işte ortak bilgi olduğu söyleniyordu) kozmik ışınların her zaman hatalar yaratmasını bekleyebilirdiniz.

"kozmik ışın olaylarının" buradaki cevapların çoğunda tekdüze bir dağılım olduğu düşünülmektedir, bu her zaman doğru olmayabilir (yani süpernova). (Wikipedia göre en azından) gelen tanım gereği "kozmik ışınlar" Her ne kadar dış mekan, ben de hiç 's adil dahil düşünüyorum yerel (aka güneş fırtınaları koronal kütle atımı aynı çatı altında. Ben a dahilinde çevirmek için birkaç bit neden olabilir inanıyoruz kısa zaman aralığı, ECC etkin belleği bile bozmaya yetecek kadar.

Güneş fırtınalarının elektrik sistemlerine oldukça fazla zarar verebileceği iyi bilinmektedir ( Mart 1989'daki Quebec elektrik kesintisi gibi ). Bilgisayar sistemlerinin de etkilenmesi muhtemeldir.

Yaklaşık 10 yıl önce başka bir adamın hemen yanında oturuyordum, her dizüstü bilgisayarımızla oturuyorduk, oldukça "fırtınalı" güneş havası olan bir dönemde (kutupta otururken, bunu dolaylı olarak gözlemleyebilirdik - bir sürü aurora borealis görüldü). Aniden - aynı anda - her iki dizüstü bilgisayarımız çöktü. OS X ve Linux kullanıyordum. İkimiz de çöken dizüstü bilgisayarlara alışkın değiliz - Linux ve OS X'te oldukça nadir bir şey. Farklı işletim sistemlerinde çalıştığımızdan beri yaygın yazılım hataları az çok göz ardı edilebilir (ve bir sıçrama sırasında olmadı) ikinci). Bu olayı "kozmik radyasyon" a atfetmeye geldim.

Daha sonra, "kozmik radyasyon" işyerimde içten bir şaka haline geldi. Sunucularımızda bir şey olduğunda ve bununla ilgili herhangi bir açıklama bulamadığımızda, hatayı şaka yaparak "kozmik radyasyon" a bağlarız. :-)

Daha sık olarak, gürültü verileri bozabilir. Checksum'lar bununla birçok seviyede mücadele etmek için kullanılır; bir veri kablosunda tipik olarak verinin yanından geçen bir eşlik biti vardır. Bu yolsuzluk olasılığını büyük ölçüde azaltır. Daha sonra ayrıştırma düzeylerinde, anlamsız veriler genellikle yok sayılır, bu nedenle bazı bozulmalar eşlik bitini veya diğer sağlama toplamlarını geçse bile, çoğu durumda yok sayılır.

Ayrıca, bazı bileşenler gürültüyü engellemek için elektrikle korunur (muhtemelen kozmik ışınlar değil).

Ama sonuçta, diğer cevaplayıcıların söylediği gibi, karıştırılan ara sıra bit veya bayt vardır ve bunun önemli bir bayt olup olmadığı şansa bırakılmıştır. En iyi durum senaryosu, bir kozmik ışın boş bitlerden birini karıştırır ve kesinlikle hiçbir etkisi yoktur veya bilgisayarı çökertir (bu iyi bir şeydir, çünkü bilgisayar zarar görmekten korunur); ama en kötü durum, eminim hayal edebileceksiniz.

Bunu yaşadım - Kozmik ışınların bir parça dönmesi nadir değildir, ancak bir kişinin bunu gözlemlemesi pek olası değildir.

2004 yılında bir yükleyici için bir sıkıştırma aracı üzerinde çalışıyordum. Test verilerim yaklaşık 500 MB veya daha fazla Adobe kurulum dosyası açmıştı.

Sıkıcı bir sıkıştırma çalışması ve bütünlüğü test etmek için bir dekompresyon çalışması sonrasında, FC / B bir bayt farklı gösterdi.

Bu bir bayt içinde MSB ters çevrilmişti. Ayrıca, sadece çok özel koşullar altında ortaya çıkacak çılgın bir böceğe sahip olduğumdan endişe duydum - nereye bakmaya başlayacağımı bile bilmiyordum.

Ama bir şey bana testi tekrar yapmamı söyledi. Ben koştum ve geçti. Testi bir gecede 5 kez çalıştırmak için bir senaryo oluşturdum. Sabah 5 kişi de geçmişti.

Bu kesinlikle kozmik bir ışın biti flipıydı.

Hata Toleranslı donanımına da göz atmak isteyebilirsiniz.

Örneğin Stratus Technology, hesaplamaların sonuçlarını karşılaştırarak kilit adımında 2 veya 3 "anakart" bulunan ftServer adlı Wintel sunucuları oluşturur. (bu bazen uzay araçlarında da yapılır).

Stratus sunucuları, özel yonga setinden arka panele kilitlenmeye dönüştü.

Çok benzer bir (ancak yazılım) sistem, Hipervizör tabanlı VMWare Hata Toleransı kilit adımdır.

Bir veri noktası olarak, bu bizim derlememizde oldu:

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  - ^

Bu, derleme sırasında, kaynak dosyada çok önemli bir yerde şans eseri gerçekleşen biraz çevirme gibi çok güçlü görünüyor.

Bunun bir "kozmik ışın" olduğunu söylemiyorum, ancak belirti uyuşuyor.