Sinar Kosmik: berapakah probabilitas mereka akan memengaruhi suatu program?

546

Sekali lagi saya berada dalam tinjauan desain, dan menemukan klaim bahwa probabilitas skenario tertentu adalah "kurang dari risiko sinar kosmik" yang memengaruhi program, dan terpikir oleh saya bahwa saya tidak tahu apa itu. probabilitas adalah.

"Karena 2 ^-128 adalah 1 dari 340282366920938463463374607431768211456, saya pikir kami dibenarkan dalam mengambil peluang kami di sini, bahkan jika perhitungan ini dimatikan oleh faktor beberapa miliar ... Kami jauh lebih berisiko terhadap sinar kosmik untuk mengacaukan kita, saya percaya. "

Apakah programmer ini benar? Berapa probabilitas sinar kosmik mengenai komputer dan memengaruhi eksekusi program?

— Mark Harrison
sumber

42

"Memenangkan Lotere: Berapa probabilitas mereka akan memengaruhi suatu program?"

— kennytm

27

Itu sebagian tergantung pada di mana program sedang dieksekusi dan seberapa baik itu dilindungi. Di Bumi, fluks sinar kosmik jauh lebih rendah daripada di ruang angkasa, atau bahkan di dekat orbit Bumi. Hubble Space Telescope, misalnya, menghasilkan gambar mentah yang penuh dengan jejak sinar kosmik.

— Adam Hollidge

89

Apakah ini berarti bahwa mulai sekarang, ketika seseorang selanjutnya bertanya tentang finallyblok, kita harus memenuhi syarat dengan "selalu dijalankan kecuali jika program keluar, atau jika dipukul dengan sinar kosmik"?

— skaffman

72

Bekerja pada pendeteksi partikel prototipe bertahun-tahun yang lalu, saya memprogramnya untuk mencetak "aduh!" setiap kali ditabrak oleh sinar kosmik. Masa-masa indah ...

— Beta

8

Salah satu pertanyaan paling menarik yang pernah saya baca di sini. Sebuah pembuka mata yang nyata. Andalkan saya untuk membuka kembali.

— Agnel Kurian

308

Dari Wikipedia :

Studi oleh IBM pada 1990-an menunjukkan bahwa komputer biasanya mengalami sekitar satu kesalahan akibat kosmik-ray per 256 megabita RAM per bulan. ^[15]

Ini berarti probabilitas 3,7 × 10 ^-9 per byte per bulan, atau 1,4 × 10 ^-15 per byte per detik. Jika program Anda berjalan selama 1 menit dan menempati 20 MB RAM, maka kemungkinan kegagalannya

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

Pemeriksaan kesalahan dapat membantu mengurangi akibat kegagalan. Juga, karena ukuran chip yang lebih ringkas seperti yang dikomentari oleh Joe, tingkat kegagalannya bisa berbeda dari 20 tahun yang lalu.

— kennytm
sumber

10

Lebih penting lagi, ukuran fitur chip untuk CPU pada tahun 1995 adalah sekitar 0,35 μm atau 350nm. Sekarang 1/10 ukuran itu pada 35nm.

— Joe Koberg

18

Apakah mungkin bahwa alih-alih mengurangi risiko, penurunan ukuran akan meningkatkan risiko karena akan membutuhkan lebih sedikit energi untuk mengubah keadaan setiap bit?

— Robert

63

Mengurangi ukuran pasti meningkatkan risiko. Prosesor yang diperkeras untuk kendaraan luar angkasa menggunakan ukuran fitur yang sangat besar untuk menghindari efek sinar kosmik.

— Joe Koberg

22

Bukan hanya sinar kosmik, isotop radioaktif dalam bahan yang digunakan dalam chip adalah masalah yang jauh lebih besar. Pembuat berusaha keras untuk memastikan silikon, solder, enkapsulasi dll tidak mengandung pemancar alfa atau beta.

— Martin Beckett

14

Wow! Ini berarti sekitar 1 byte di PC saya rusak setiap dua hari.

— Stefan Monov

91

Ternyata, tidak sepele. Dari artikel New Scientist ini , kutipan dari aplikasi paten Intel:

"Kecelakaan komputer yang disebabkan oleh sinar kosmik telah terjadi dan diperkirakan akan meningkat seiring frekuensi ketika perangkat (misalnya, transistor) mengurangi ukuran chip. Masalah ini diproyeksikan menjadi pembatas utama keandalan komputer dalam dekade berikutnya."

Anda dapat membaca paten selengkapnya di sini .

— ire_and_curses
sumber

7

Mengapa mereka meningkat dengan penurunan ukuran chip? Tentunya benda yang lebih kecil kemungkinannya tidak akan terkena sinar (yaitu membandingkan melempar bola tenis ke dinding, melemparkannya ke perangko)

— Jonathan.

7

Karena ketika ukuran komponen menyusut, mereka menjadi jauh lebih sensitif terhadap serangan sinar kosmik.

— ire_and_curses

4

Ya, lebih kecil sama dengan kecil kemungkinan terkena, tetapi lebih besar kemungkinan bahwa pukulan akan mempengaruhi negara.

— John Hascall

2

@ire_and_curses [rujukan?]

— Anko

8

@Anko - Ini agak jelas. Sebagai komponen yang diberikan semakin kecil, itu membutuhkan lebih sedikit tegangan dan biaya lebih sedikit untuk mengatur sedikit. Itu membuatnya lebih sensitif untuk diledakkan dengan energi dari luar angkasa. Namun, inilah kutipan untuk Anda: Ketika perangkat memori LSI menjadi lebih kecil, mereka menjadi lebih sensitif terhadap kegagalan soft-induced radiasi-nuklir.

— ire_and_curses

55

catatan: jawaban ini bukan tentang fisika, tetapi tentang kesalahan memori diam dengan modul memori non-ECC. Beberapa kesalahan mungkin berasal dari luar angkasa, dan beberapa - dari ruang dalam desktop.

Ada beberapa studi tentang kegagalan memori ECC pada server pertanian besar seperti cluster CERN dan pusat data Google. Perangkat keras kelas server dengan ECC dapat mendeteksi dan memperbaiki semua kesalahan bit tunggal, dan mendeteksi banyak kesalahan multi-bit.

Kita dapat berasumsi bahwa ada banyak desktop non-ECC (dan ponsel cerdas non-ECC). Jika kita memeriksa kertas untuk tingkat kesalahan yang dapat diperbaiki ECC (bitflips tunggal), kita dapat mengetahui tingkat kerusakan kehabisan memori pada memori non-ECC.

Studi CERN 2007 skala besar "Integritas data" : vendor menyatakan " Tingkat Kesalahan Bit 10 ^-12 untuk modul memori mereka ", " tingkat kesalahan yang diamati adalah 4 kali lipat lebih rendah dari yang diharapkan ". Untuk tugas-tugas intensif data (8 GB / s membaca memori) ini berarti bahwa flip bit tunggal dapat terjadi setiap menit (10 ^-12 vendor BER) atau sekali dalam dua hari (10 ^-16 BER).
Makalah Google 2009 "Kesalahan DRAM di Alam: Studi Lapangan Skala Besar" mengatakan bahwa mungkin ada 25.000-75.000 FIT per-bit per Mbit ( kegagalan dalam waktu per miliar jam ), yang sama dengan 1 - 5 bit kesalahan per jam untuk 8GB RAM setelah perhitungan saya. Makalah mengatakan hal yang sama: " berarti tingkat kesalahan yang dapat diperbaiki 2000-6000 per GB per tahun ".
Laporan Sandia 2012 "Deteksi dan Koreksi Korupsi Data Senyap untuk Komputasi Kinerja Tinggi Skala Besar" : "flips bit ganda dianggap tidak mungkin" tetapi pada ORNL's Cray XT5 yang padat mereka "pada laju satu per hari untuk 75.000+ DIMM" bahkan dengan ECC. Dan kesalahan bit tunggal harus lebih tinggi.

Jadi, jika program memiliki dataset besar (beberapa GB), atau memiliki tingkat baca atau tulis memori yang tinggi (GB / s atau lebih), dan itu berjalan selama beberapa jam, maka kita dapat mengharapkan beberapa bit bit diam pada perangkat keras desktop. Tingkat ini tidak dapat dideteksi oleh memtest, dan modul DRAM baik.

Cluster panjang berjalan pada ribuan PC non-ECC, seperti komputasi grid luas internet BOINC akan selalu memiliki kesalahan dari memori bit-flip dan juga dari kesalahan disk dan jaringan diam.

Dan untuk mesin yang lebih besar (10 ribu server) bahkan dengan perlindungan ECC dari kesalahan bit tunggal, seperti yang kita lihat dalam laporan Sandia 2012, bisa ada flips bit ganda setiap hari, sehingga Anda tidak akan memiliki peluang untuk menjalankan paralel ukuran penuh program selama beberapa hari (tanpa pemeriksaan rutin dan memulai kembali dari pemeriksaan bagus terakhir jika terjadi kesalahan ganda). Mesin-mesin besar juga akan mendapatkan bit-flip dalam cache dan register cpu mereka (baik pemicu arsitektur dan internal chip misalnya dalam ALU datapath), karena tidak semua dari mereka dilindungi oleh ECC.

PS: Keadaan akan jauh lebih buruk jika modul DRAM buruk. Sebagai contoh, saya menginstal DRAM baru ke laptop, yang mati beberapa minggu kemudian. Itu mulai memberi banyak kesalahan memori. Apa yang saya dapatkan: laptop hang, linux reboot, menjalankan fsck, menemukan kesalahan pada root filesystem dan mengatakan ingin melakukan reboot setelah memperbaiki kesalahan. Tetapi pada setiap reboot berikutnya (saya lakukan sekitar 5-6 dari mereka) masih ada kesalahan yang ditemukan pada sistem file root.

— osgx
sumber

9

Materi tambahan dari BH 2011: "Bitsquatting. Pembajakan DNS tanpa eksploitasi" media.blackhat.com/bh-us-11/Dinaburg/… daftar DRAM multi-GB modern untuk memiliki sekitar 10.000-30000 FIT / Mbit (kurang dari 100 jam antara kesalahan untuk setiap 128MB). Makalah ini juga mendaftar artikel yang menyimpulkan bahwa sebagian besar kesalahan lunak berasal dari radiasi, hampir semua kasus - dari sinar kosmik, dan beberapa kasus dari pemancar alfa di dalam PC. Penulis BH melakukan percobaan dan mendapat 50000 akses ke domain, setelah 1 bit diubah dari situs populer

— osgx

Kudos untuk menambahkan lebih banyak studi terbaru di sini. Mengingat dinamika pemungutan suara SO dan bagaimana akumulasi mereka dari waktu ke waktu, sangat sulit untuk memiliki presentasi terkini tentang topik ini yang menonjol (di sini).

— Fizz

Kami memiliki masalah serupa. Kami tidak melakukan penelitian yang pasti, tetapi kami memiliki beberapa dump crash dengan bit terlihat terbalik. Kami memeriksa bit-bit itu terbalik dan ternyata mereka berada di bagian kode. Kami membandingkan dengan apa yang seharusnya ada di sana dan itu tidak terlihat seperti modifikasi yang disengaja (yaitu instruksi yang dihasilkan tidak masuk akal). Pada akhirnya kami memiliki aplikasi sederhana, yang membandingkan crash dumps dengan versi yang diarsipkan dan menyaring kasus-kasus tersebut. Menariknya saya pikir sebagian besar kasus seperti itu berasal dari Iran, Arab dan saya pikir satu negara lagi dari Amerika Selatan (tidak ingat sekarang).

— GiM

2

Dalam makalah Google, ini lebih mirip kasus bahwa beberapa RAM buruk. Sekitar sepertiga mesin dan lebih dari 8% DIMM dalam armada kami melihat setidaknya satu kesalahan yang dapat diperbaiki per tahun. Rasio kesalahan terkoreksi per-DIMM kami menerjemahkan hingga rata-rata 25.000–75.000 FIT (kegagalan dalam waktu per miliar jam operasi) per Mbit dan rentang FIT median 778 - 25.000 per Mbit (median untuk DIMM dengan kesalahan), sementara studi sebelumnya melaporkan 200-5.000 FIT per Mbit. Jumlah kesalahan yang dapat diperbaiki per DIMM sangat bervariasi, dengan beberapa DIMM mengalami sejumlah besar kesalahan, dibandingkan dengan yang lain.

— vartec

31

Wikipedia mengutip sebuah studi oleh IBM di tahun 90-an yang menyatakan bahwa "komputer biasanya mengalami satu kesalahan yang diinduksi oleh sinar kosmik per 256 megabyte RAM per bulan." Sayangnya kutipannya adalah artikel di Scientific American, yang tidak memberikan referensi lebih lanjut. Secara pribadi, saya menemukan angka itu sangat tinggi, tetapi mungkin sebagian besar kesalahan memori yang disebabkan oleh sinar kosmik tidak menyebabkan masalah aktual atau masalah nyata.

Di sisi lain, orang berbicara tentang probabilitas ketika datang ke skenario perangkat lunak biasanya tidak tahu apa yang mereka bicarakan.

— JesperE
sumber

7

Probabilitas bit yang dibalik harus dikalikan dengan probabilitas bit memiliki pengaruh yang nyata pada program. Saya menduga probabilitas kedua jauh lebih rendah daripada yang Anda pikirkan.

— Mark Ransom

2

@ Mark: Program komputer biasa tidak memiliki built-in toleransi kesalahan seperti itu. Kesalahan bit tunggal dalam kode program akan lebih besar kemungkinannya daripada merusak program, jika kode yang rusak dijalankan.

— Robert Harvey

75

Ya, tetapi sebagian besar memori berisi data, di mana flip tidak akan menjadi visiblp itu.

— zoul

34

@ zoul. lol di 'visiblp', tetapi jika e = 1100101 dan p = 1110000 maka Anda adalah korban sial dari 3 bit flips!

— PaulG

10

@ Paul: atau blip satu jari.

— mpen

30

Yah, sinar kosmik rupanya menyebabkan elektronik di mobil Toyota tidak berfungsi, jadi saya akan mengatakan bahwa probabilitasnya sangat tinggi :)

Apakah sinar kosmik benar-benar menyebabkan kesengsaraan Toyota?

— Kevin Crowell
sumber

23

"Regulator Federal sedang mempelajari apakah akselerasi mendadak di Toyota terkait dengan sinar kosmik." Inilah sebabnya mengapa Anda seharusnya tidak pernah memberi kekuasaan regulator federal atas hidup Anda.

13

Saya kira teorinya di sini adalah bahwa sinar kosmik membalik bit di otak yang lebih tua menyebabkan mereka tidak berfungsi dan menekan pedal yang salah.

— Knox

16

"Tampaknya"? Saya akan mengatakan itu dugaan liar pada titik ini. Dugaan liar saya adalah bahwa fenomena ini adalah hasil dari mimpi buruk lama dari sistem embedded (sebenarnya sistem komputer yang paling kompleks) - kondisi balapan.

— Michael Burr

7

@Knox: Buka topi kertas timah tua Anda, ini berguna!

3

Itu mungkin bukan lelucon. Saya telah melihat beberapa hal aneh yang serius seperti itu terjadi sebelumnya. Tidak jarang seperti yang dipikirkan kebanyakan orang.

— Brian Knoblauch

25

Dengan ECC Anda dapat memperbaiki kesalahan 1 bit dari Cosmic Rays. Untuk menghindari 10% kasus di mana sinar kosmik menghasilkan 2-bit-error, sel-sel ECC biasanya disisipkan di atas chip sehingga tidak ada dua sel yang bersebelahan. Peristiwa sinar kosmik yang mempengaruhi dua sel karenanya akan menghasilkan dua kesalahan 1bit yang dapat diperbaiki.

Sun menyatakan: (Bagian No. 816-5053-10 April 2002)

Secara umum, kesalahan soft cosmic ray terjadi dalam memori DRAM pada tingkat ~ 10 hingga 100 FIT / MB (1 FIT = 1 perangkat gagal dalam 1 miliar jam). Jadi sistem dengan 10 GB memori harus menunjukkan acara ECC setiap 1.000 hingga 10.000 jam, dan sistem dengan 100 GB akan menampilkan acara setiap 100 hingga 1.000 jam. Namun, ini adalah perkiraan kasar yang akan berubah sebagai fungsi dari efek yang diuraikan di atas.

— eckes
sumber

17

Kesalahan memori itu nyata, dan memori ECC memang membantu. Memori ECC yang diterapkan dengan benar akan memperbaiki kesalahan bit tunggal dan mendeteksi kesalahan bit ganda (menghentikan sistem jika kesalahan seperti itu terdeteksi.) Anda dapat melihat ini dari seberapa sering orang mengeluh tentang apa yang tampaknya menjadi masalah perangkat lunak yang diselesaikan dengan menjalankan Memtest86 dan menemukan memori buruk. Tentu saja kegagalan sementara yang disebabkan oleh sinar kosmik berbeda dengan sepotong memori yang gagal secara konsisten, tetapi relevan dengan pertanyaan yang lebih luas tentang seberapa besar Anda harus memercayai memori Anda untuk beroperasi dengan benar.

Analisis yang didasarkan pada ukuran penduduk 20 MB mungkin sesuai untuk aplikasi sepele, tetapi sistem besar secara rutin memiliki beberapa server dengan memori utama yang besar.

Tautan menarik: http://cr.yp.to/hardware/ecc.html

Sayangnya, tautan Corsair di halaman itu sudah mati.

— janm
sumber

Bitflips sinar kosmik mungkin tidak terdistribusi secara seragam, terutama jika kita memasukkan badai matahari di bawah "payung sinar kosmik". Jika Anda mendapat dua atau lebih bitflips dalam byte yang sama, ECC tipikal tidak akan dapat memperbaiki kesalahan.

— tobixen

@tobixen Mendeteksi kesalahan bit ganda lebih baik daripada terus berjalan dengan data yang buruk. Langkah selanjutnya setelah ECC adalah Chipkill dengan mirroring DIMM ...

— janm

13

Ini adalah masalah nyata, dan itulah sebabnya memori ECC digunakan di server dan sistem embedded. Dan mengapa sistem terbang berbeda dari yang berbasis darat.

Misalnya, perhatikan bahwa komponen Intel yang ditujukan untuk aplikasi "tertanam" cenderung menambahkan ECC ke lembar spesifikasi. Bay Trail untuk tablet tidak memilikinya, karena itu akan membuat memori sedikit lebih mahal dan mungkin lebih lambat. Dan jika tablet crash program sekali dalam bulan biru, pengguna tidak terlalu peduli. Perangkat lunak itu sendiri jauh lebih tidak dapat diandalkan daripada HW. Tetapi untuk SKU yang dimaksudkan untuk digunakan dalam mesin industri dan otomotif, ECC adalah wajib. Karena di sini, kami berharap SW jauh lebih andal, dan kesalahan dari gangguan acak akan menjadi masalah nyata.

Sistem yang disertifikasi untuk IEC 61508 dan standar serupa biasanya memiliki kedua tes boot-up yang memeriksa bahwa semua RAM berfungsi (tidak ada bit yang macet pada nol atau satu), serta penanganan kesalahan pada saat runtime yang mencoba untuk pulih dari kesalahan yang terdeteksi oleh ECC, dan sering juga tugas-tugas scrubber memori yang melalui dan membaca dan menulis memori terus menerus untuk memastikan bahwa setiap kesalahan yang terjadi dapat diketahui.

Tetapi untuk perangkat lunak PC mainstream? Bukan masalah besar. Untuk server berumur panjang? Gunakan ECC dan penangan kesalahan. Jika kesalahan yang tidak dapat diperbaiki membunuh kernel, maka lakukanlah. Atau Anda menjadi paranoid dan menggunakan sistem redundan dengan eksekusi kunci-langkah sehingga jika satu core rusak, yang lain bisa mengambil alih ketika core pertama reboot.

— jakobengblom2
sumber

Bitflips sinar kosmik mungkin tidak terdistribusi secara seragam, terutama jika kita memasukkan badai matahari di bawah "payung sinar kosmik". Ledakan mendadak dapat menyebabkan beberapa bitflips dalam satu byte, dan algoritma ECC tidak akan dapat memperbaiki kegagalan.

— tobixen

12

Jika sebuah program kritis terhadap kehidupan (itu akan membunuh seseorang jika gagal), program itu harus ditulis sedemikian rupa sehingga akan gagal-aman, atau pulih secara otomatis dari kegagalan tersebut. Semua program lain, YMMV.

Toyota adalah contohnya. Katakan apa yang Anda mau tentang kabel throttle, tetapi ini bukan perangkat lunak.

Lihat juga http://en.wikipedia.org/wiki/Therac-25

— Robert Harvey
sumber

Jangankan perangkat lunak untuk throttles. Sensor dan kabel untuk throttle adalah titik lemahnya. Sensor posisi throttle Mitsubishi saya gagal menjadi generator angka acak ... Tidak ada akselerasi yang tidak disengaja, tapi itu pasti tidak melakukan sesuatu yang baik untuk campuran bahan bakar!

— Brian Knoblauch

3

@Brian: Perangkat lunak yang baik akan menemukan bahwa titik data terputus, dan menyimpulkan bahwa datanya buruk.

— Robert Harvey

..dan lalu apa ... Data yang baik diperlukan. Mengetahui itu buruk tidak membantu. Bukan sesuatu yang bisa Anda atasi secara ajaib.

— Brian Knoblauch

3

@ Brian: Ya, untuk satu hal, Anda dapat mengambil tindakan korektif berdasarkan pengetahuan bahwa data Anda buruk. Anda dapat berhenti mempercepat, misalnya.

— Robert Harvey

Ya, Anda dapat (dan harus) data cheksum. Terbaik ujung ke ujung. Namun ini hanya mengurangi kemungkinan korupsi. Bayangkan instruksi "apakah ini valid" Anda mendapatkan sedikit kerusakan dalam memori atau register CPU hanya ketika Anda ingin melakukan cabang ke penangan kesalahan.

— eckes

11

Saya pernah memprogram perangkat yang terbang di luar angkasa, dan kemudian Anda (seharusnya, tidak ada yang pernah menunjukkan kepada saya kertas tentang hal itu, tetapi dikatakan sebagai pengetahuan umum dalam bisnis) dapat mengharapkan sinar kosmik untuk menyebabkan kesalahan sepanjang waktu.

— erikkallen
sumber

8

Di atas atmosfer dua hal terjadi: 1) fluks total lebih tinggi 2) lebih banyak lagi datang dalam bentuk partikel yang sangat energik (dengan energi yang cukup untuk membalikkan sedikit dikemas ke dalam ruang kecil).

— dmckee --- ex-moderator kitten

Berkenaan dengan referensi, ada buku (misalnya, books.google.com/books?hl=id&lr=&id=Er5_rzW0q3MC ), konferensi (misalnya, radecs2015.org , sepertinyaapld.org , dan lainnya), dan makalah yang banyak membahas topik ini . Sinar kosmik bukan lelucon di aerospace. Mereka adalah salah satu alasan utama bahwa banyak wahana antariksa menggunakan komputer yang dikeraskan, yang sebagian besar memiliki kekuatan pemrosesan oven pemanggang roti pintar modern.

— David Hammen

8

"peristiwa sinar kosmik" dianggap memiliki distribusi yang seragam dalam banyak jawaban di sini, ini mungkin tidak selalu benar (yaitu supernova). Meskipun "sinar kosmik" menurut definisi (setidaknya menurut Wikipedia) berasal dari luar angkasa, saya pikir wajar juga untuk memasukkan badai matahari lokal (alias ejeksi massa koronal) bawah payung yang sama. Saya percaya itu dapat menyebabkan beberapa bit untuk tergelincir dalam suatu jangka waktu pendek, cukup berpotensi untuk merusak bahkan memori yang mendukung ECC.

Sudah diketahui umum bahwa badai matahari dapat menyebabkan malapetaka dengan sistem listrik (seperti pemadaman listrik Quebec pada Maret 1989) ). Sangat mungkin bahwa sistem komputer juga dapat terpengaruh.

Sekitar 10 tahun yang lalu saya duduk tepat di sebelah pria lain, kami duduk dengan laptop masing-masing, itu dalam periode dengan cuaca matahari cukup "badai" (duduk di Arktik, kita bisa mengamati ini secara tidak langsung - banyak aurora borealis ke terlihat). Tiba-tiba - pada saat yang sama - kedua laptop kami mogok. Dia menjalankan OS X, dan saya menjalankan Linux. Tidak satu pun dari kita yang terbiasa dengan laptop yang mogok - itu adalah hal yang sangat langka di Linux dan OS X. Bug perangkat lunak umum dapat lebih atau kurang dapat dikesampingkan karena kami menjalankan pada OS yang berbeda (dan itu tidak terjadi selama lompatan kedua). Saya datang untuk menghubungkan peristiwa itu dengan "radiasi kosmik".

Belakangan, "radiasi kosmik" telah menjadi lelucon internal di tempat kerja saya. Setiap kali sesuatu terjadi dengan server kami dan kami tidak dapat menemukan penjelasan untuk itu, kami bercanda atribut kesalahan untuk "radiasi kosmik". :-)

— tobixen
sumber

7

Lebih sering, noise dapat merusak data. Checksum digunakan untuk melawan ini di banyak tingkatan; dalam kabel data biasanya ada bit paritas yang bergerak di samping data. Ini sangat mengurangi kemungkinan korupsi. Kemudian pada level parsing, data nonsense biasanya diabaikan, jadi bahkan jika beberapa korupsi tidak melewati bit paritas atau checksum lainnya, dalam banyak kasus akan diabaikan.

Juga, beberapa komponen terlindung secara elektrik untuk memblokir kebisingan (mungkin bukan sinar kosmik yang saya kira).

Tetapi pada akhirnya, seperti yang dikatakan oleh penjawab lain, ada bit atau byte sesekali yang teracak, dan terserah peluang apakah itu byte signifikan atau tidak. Skenario kasus terbaik, sinar kosmik mengacak salah satu bit kosong dan sama sekali tidak berpengaruh, atau membuat crash komputer (ini adalah hal yang baik, karena komputer dijaga agar tidak membahayakan); tetapi kasus terburuk, well, saya yakin Anda bisa membayangkan.

— Ricket
sumber

Bitflips sinar kosmik mungkin tidak terdistribusi secara seragam, terutama jika kita memasukkan badai matahari di bawah "payung sinar kosmik". Jika Anda mendapatkan dua bit bit dalam byte yang sama, pemeriksaan bit paritas akan gagal. Beberapa bitflips, dan algoritma ECC mungkin tidak akan dapat memperbaiki kegagalan.

— tobixen

5

Saya pernah mengalami ini - Tidak jarang sinar kosmik terbalik sedikit, tetapi sangat tidak mungkin seseorang mengamati ini.

Saya sedang mengerjakan alat kompresi untuk installer pada tahun 2004. Data pengujian saya adalah beberapa file instalasi Adobe sekitar 500 MB atau lebih terdekompresi.

Setelah menjalankan kompresi yang membosankan, dan menjalankan dekompresi untuk menguji integritas, FC / B menunjukkan satu byte yang berbeda.

Dalam satu byte itu MSB telah terbalik. Saya juga membalik, khawatir bahwa saya memiliki bug gila yang hanya akan muncul di bawah kondisi yang sangat spesifik - saya bahkan tidak tahu harus mulai dari mana.

Tapi ada yang memberitahuku untuk menjalankan tes lagi. Saya menjalankannya dan itu berlalu. Saya membuat skrip untuk menjalankan tes 5 kali dalam semalam. Di pagi hari semua 5 telah berlalu.

Jadi itu pasti flip bit sinar kosmik.

— rep_movsd
sumber

Pastinya? Tidak bisakah itu merupakan variabel tidak diinisialisasi yang tidak pernah mendapatkan nilai awal yang buruk dalam pengujian selanjutnya?

— doug65536

Saya selalu mengkompilasi dengan W3 atau W4 pada VS - Juga Rasional Purify, tidak ada bug semacam itu.

— rep_movsd

Ah, maaf saya tidak tahu bahwa opsi-opsi kompiler dan Pemurnian Rasional benar-benar sempurna. =)

— doug65536

Menimbang bahwa kode tersebut kemudian dimasukkan ke dalam produksi dan dikompresi dan dikompresi ratusan GB dengan benar, tidak ada tanda-tanda bug yang sama.

— rep_movsd

4

Anda mungkin ingin melihat perangkat keras Fault Tolerant juga.

Sebagai contoh Stratus Technology membangun server Wintel yang disebut ftServer yang memiliki 2 atau 3 "mainboards" dalam langkah-kunci, membandingkan hasil perhitungan. (Terkadang ini juga dilakukan di kendaraan luar angkasa).

Server Stratus berevolusi dari chipset khusus menjadi pengunci di backplane.

Sistem yang sangat mirip (tetapi perangkat lunak) adalah VMWare Fault Tolerance lockstep berdasarkan Hypervisor.

— eek
sumber

4

Sebagai titik data, ini baru saja terjadi pada versi kami:

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

Itu terlihat sangat kuat seperti sedikit flip terjadi selama kompilasi, di tempat yang sangat signifikan dalam file sumber secara kebetulan.

Saya tidak perlu mengatakan ini adalah "sinar kosmik", tetapi gejalanya cocok.

— omong kosong
sumber