Космічні промені: яка ймовірність впливу на програму?

Я знову опинився в огляді дизайну і зіткнувся з твердженням, що ймовірність того чи іншого сценарію "менше, ніж ризик космічних променів" впливати на програму, і мені прийшло в голову, що я не маю найменшого уявлення про те, що це ймовірність є.

"Оскільки 2 ^-128 - це 1 з 340282366920938463463374607431768211456, я думаю, що ми виправдані, щоб ризикувати тут, навіть якщо ці обчислення вимикаються в кілька мільярдів ... Ми набагато більше ризикуємо, що космічні промені виверніть нас, я вважаю ».

Правильний цей програміст? Яка ймовірність попадання космічного променя на комп’ютер і впливає на виконання програми?

З Вікіпедії :

Дослідження IBM у 90-х роках показують, що комп'ютери, як правило, мають приблизно одну помилку, викликану космічними променями, на 256 мегабайт оперативної пам’яті на місяць. ^[15]

Це означає ймовірність 3,7 × 10 ^-9 за байт на місяць, або 1,4 × 10 ^-15 за байт в секунду. Якщо ваша програма працює 1 хвилину і займає 20 Мб оперативної пам’яті, то ймовірність відмови буде

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

Перевірка помилок може допомогти зменшити наслідки відмови. Крім того, через більш компактний розмір чіпів, як коментує Джо, рівень відмов може відрізнятися від того, який був 20 років тому.

Мабуть, несуттєво. З цієї статті New Scientist , цитата із заявки на патент Intel:

"Космічні промені, спричинені космічними променями, сталися і, як очікується, збільшуватимуться з частотою, оскільки пристрої (наприклад, транзистори) зменшують розмір мікросхем. За прогнозами, ця проблема стане головним обмежувачем надійності комп'ютера в наступному десятилітті".

Повний патент ви можете прочитати тут .

Примітка: ця відповідь стосується не фізики, а помилок тихої пам'яті з модулями пам'яті, що не належить до ECC. Деякі помилки можуть виникнути з космосу, а деякі - з внутрішнього простору робочого столу.

Існує кілька досліджень відмов пам’яті ECC на великих фермах серверів, таких як кластери CERN та центри обробки даних Google. Обладнання серверного класу з ECC може виявляти та виправляти всі одиночні бітові помилки та виявляти багато багатобітних помилок.

Ми можемо припустити, що настільних ПК (і не-ECC мобільних смартфонів) існує безліч настільних комп'ютерів, які не є ECC. Якщо ми перевіримо папери на предмет коефіцієнтів помилок, що виправляються за ECC (поодинокі бітфліпи), ми можемо знати швидкість пошкодження пам’яті безшумної пам’яті, що не належить до ECC.

• Широкомасштабне дослідження CERN 2007 "Цілісність даних" : постачальники заявляють " Швидкість помилок бітів 10 ^-12 для модулів пам'яті ", " спостережуваний коефіцієнт помилок на 4 порядки нижче, ніж очікувалося ". Для об'ємних даних (8 Гб / с зчитування пам'яті) це означає, що один біт перегортання може відбуватися щохвилини (10 ^-12 постачальників BER) або один раз на два дні (10 ^-16 BER).

• У статті Google "Помилки DRAM в дикій природі: широкомасштабне поле дослідження" говориться, що може бути до 25000-75000 однорозрядних FIT на Мбіт ( невдачі в часі на мільярд годин ), що дорівнює 1 - 5 біт помилки за годину для 8 ГБ оперативної пам’яті після моїх розрахунків. У роботі сказано те саме: " середні виправні коефіцієнти помилок 2000–6000 на ГБ на рік ".

• Звіт Sandia 2012 року "Виявлення та виправлення безшумних пошкоджень даних для широкомасштабних високоефективних обчислень" : "подвійні бітові гортання вважаються малоймовірними", але в густому Cray XT5 ORNL вони "з розрахунку один на день для 75000+ DIMM" навіть з ECC. І однобітних помилок повинно бути вище.

Отже, якщо програма має великий набір даних (кілька ГБ) або має високу швидкість читання або запису пам'яті (ГБ / с або більше), і вона працює протягом декількох годин, то ми можемо очікувати до декількох мовчазних бітових переворотів на апаратному забезпеченні робочого столу. Ця швидкість не виявляється за допомогою метеста, і DRAM-модулі добре.

Довгий кластер працює на тисячах комп'ютерів, що не належать до ЕКС, як, наприклад, мережеві обчислення BOINC в Інтернеті, завжди матимуть помилки в біткових обертах пам’яті, а також від помилок на диску та в мережі.

А для більших машин (10 тис. Серверів) навіть із захистом ECC від однобітних помилок, як ми бачимо у звіті Sandia за 2012 рік, можна робити подвійні біти фліп щодня, так що у вас не буде шансів запустити паралель повнорозмірного розміру програма на кілька днів (без регулярної контрольної точки та перезавантаження з останньої хорошої контрольної точки у разі подвійної помилки). Величезні машини також отримають біт-фліп у своїх кешах та регістрах процесорів (як архітектурні, так і внутрішні мікросхеми, наприклад, на шляху даних ALU), оскільки не всі вони захищені ECC.

PS: Все буде набагато гірше, якщо модуль DRAM поганий. Наприклад, я встановив нову DRAM в ноутбук, який помер через кілька тижнів. Це почало створювати багато помилок пам'яті. Що я отримую: ноутбук зависає, Linux перезавантажується, запускає fsck, знаходить помилки в кореневій файловій системі та каже, що хоче зробити перезавантаження після виправлення помилок. Але при кожному наступному перезавантаженні (я робив близько 5-6 з них) все ще виявляються помилки в кореневій файловій системі.

Вікіпедія цитує дослідження IBM у 90-х роках, що припускає, що "комп'ютери, як правило, мають одну помилку, викликану космічними променями, на 256 мегабайт оперативної пам'яті на місяць". На жаль, цитування було до статті в Scientific American, яка не дала жодних посилань. Особисто я вважаю це число дуже високим, але, мабуть, більшість помилок пам'яті, викликаних космічними променями, не викликають жодних реальних або помітних проблем.

З іншого боку, люди, які говорять про ймовірності, коли мова йде про програмні сценарії, зазвичай не мають поняття, про що вони говорять.

Що ж, космічні промені, очевидно, призвели до несправності електроніки в автомобілях Toyota, тому я б сказав, що ймовірність дуже висока :)

Чи насправді космічні промені викликають горе в Тойоті?

За допомогою ECC ви можете виправити 1-бітні помилки Cosmic Rays. Щоб уникнути 10% випадків, коли космічні промені призводять до 2-бітових помилок, комірки ECC, як правило, перемежовуються над мікросхемами, так що жодні дві комірки не знаходяться поруч. Отже, подія космічного проміння, яке впливає на дві клітини, призведе до двох виправних 1-бітових помилок.

Сонце: (частина № 816-5053-10 квітня 2002 р.)

Взагалі кажучи, м'які помилки космічних променів трапляються в пам'яті DRAM зі швидкістю від 10 до 100 FIT / MB (1 FIT = 1 пристрій виходить з ладу за 1 мільярд годин). Таким чином, система з 10 ГБ пам’яті повинна показувати подію ECC кожні 1000 до 10000 годин, а система з 100 ГБ показуватиме події кожні 100-1000 годин. Однак це приблизна оцінка, яка зміниться у залежності від ефектів, викладених вище.

Помилки пам’яті справжні, і ECC пам’ять справді допомагає. Правильно реалізована пам'ять ECC виправить одиночні бітові помилки та виявить подвійні бітові помилки (зупиняє систему, якщо така помилка виявлена.) Ви можете це бачити, як регулярно люди скаржаться на те, що, здається, є проблема програмного забезпечення, вирішена за допомогою Memtest86 та виявлення поганої пам’яті. Звичайно, тимчасовий збій, викликаний космічним промінням, відрізняється від послідовно невдалого фрагмента пам'яті, але це стосується більш широкого питання про те, наскільки ви повинні довіряти своїй пам'яті для правильної роботи.

Аналіз, заснований на розмірі мешканця 20 Мб, може бути доречним для тривіальних додатків, але у великих системах зазвичай є кілька серверів з великою основною пам'яттю.

Цікаве посилання: http://cr.yp.to/hardware/ecc.html

На жаль, посилання Корсар на сторінці, на жаль, мертве.

Це справжня проблема, і саме тому пам'ять ECC використовується на серверах та вбудованих системах. І чому літаючі системи відрізняються від наземних.

Наприклад, зауважте, що частини Intel, призначені для "вбудованих" додатків, як правило, додають ECC до аркуша специфікації. Програми Bay Trail для планшета не вистачає, оскільки це зробить пам'ять трохи дорожче і, можливо, повільніше. І якщо планшет щоразу під час синього місяця збоїть програму, користувач не сильно піклується. Програмне забезпечення набагато менш надійне, ніж HW у будь-якому випадку. Але для товарних позицій, призначених для використання у промислових машинах та автомобілях, ECC є обов'язковим. Оскільки тут ми очікуємо, що ПЗ буде набагато надійнішим, а помилки випадкових розладів будуть справжньою проблемою.

Системи, сертифіковані за стандартом IEC 61508 та подібними стандартами, зазвичай мають як тести завантаження, що перевіряють функціональність оперативної пам’яті (жодних біт не застряг у нулі, ні одна), а також обробку помилок під час виконання, яка намагається відновити помилки, виявлені ECC, і часто також виконуються завдання з вимивання пам'яті, які постійно проходять і читають і записують пам'ять, щоб переконатися, що будь-які помилки, що трапляються, помічаються.

Але для програмного забезпечення для ПК? Не велике діло. Для довгожителя сервера? Використовуйте ECC та обробку несправностей. Якщо ядро ​​вбиває нерегульоване, так і нехай буде. Або ви переходите до параноїдальних і використовуєте резервну систему із виконанням блокування, так що якщо одне ядро ​​зіпсується, інше може перейняти, коли перше ядро ​​перезавантажується.

Якщо програма є життєво важливою (вона вб'є когось, якщо вона вийде з ладу), вона повинна бути написана таким чином, що вона буде або безвідмовною, або відновиться автоматично після такого збою. Всі інші програми, YMMV.

Тойоти - це конкретний випадок. Скажіть, що ви будете з дроселем, але це не програмне забезпечення.

Дивіться також http://en.wikipedia.org/wiki/Therac-25

Я колись запрограмував пристрої, які мали б літати в космосі, і тоді ви (нібито, мені ніхто ніколи не показував жодного паперу про це, але, як кажуть, це було загальновідомо в бізнесі), ви могли очікувати, що космічні промені весь час викликатимуть помилки.

У багатьох відповідях тут "події космічних променів" вважаються рівномірними, це не завжди може бути правдою (тобто, суперновою). Хоча «космічних променів» за визначенням (по крайней мере , згідно Вікіпедії) надходить з зовнішнього простору, я думаю , що це справедливо також включати місцеві сонячні бурі ( так званий викид корональної маси під одним дахом. Я вважаю , що це може призвести до кілька бітів , щоб перевернути в межах короткий проміжок часу, потенційно достатній для пошкодження навіть пам’яті з підтримкою ECC.

Загальновідомо, що сонячні бурі можуть спричинити загрозу з електричними системами (наприклад, відключення електроенергії в Квебеку в березні 1989 року ). Цілком ймовірно, що на це можуть вплинути і комп'ютерні системи.

Якихось 10 років тому я сидів поруч з іншим хлопцем, ми сиділи з кожним нашим ноутбуком, це було в період досить бурхливої ​​сонячної погоди (сидячи в Арктиці, ми могли це спостерігати опосередковано - багато aurora borealis бути побаченим). Раптом - в ту саму мить - обидва наші ноутбуки розбилися. Він керував OS X, а я працював Linux. Ніхто з нас не звик до збоїв у ноутбуках - це досить рідкісна річ в Linux і OS X. Поширені програмні помилки можна більш-менш виключити, оскільки ми працювали на різних ОС (а це не відбулося під час стрибка другий). Я прийшов віднести цю подію до "космічного випромінювання".

Пізніше "космічне випромінювання" стало внутрішнім жартом на моєму робочому місці. Щоразу, коли щось трапляється з нашими серверами, і ми не можемо знайти жодного пояснення для цього, ми жартома приписуємо свою вина "космічному випромінюванню". :-)

Частіше шум може зіпсувати дані. Для боротьби з цим на багатьох рівнях використовуються контрольні суми ; у кабелі даних зазвичай є біт парності, який рухається поряд з даними. Це значно знижує ймовірність корупції. Тоді на рівнях розбору дані дурниць, як правило, ігноруються, тому, навіть якщо якась корупція не пройшла біт парності чи інші контрольні суми, вона в більшості випадків буде ігнорована.

Крім того, деякі компоненти електрично екрановані для блокування шуму (мабуть, не космічні промені, я думаю).

Але врешті-решт, як сказали інші відповіді, є випадковий біт або байт, який стає скремблированним, і це залишається випадковістю, чи є це значним байтом чи ні. У кращому випадку, космічний промінь перебирає один із порожніх бітів і не робить абсолютно ніякого ефекту, або виходить з ладу комп'ютер (це добре, адже комп'ютер утримує від шкоди); але в гіршому випадку, ну, я впевнений, ви можете це уявити

Я це переживав - Космічні промені не рідко перевертають один шматочок, але дуже малоймовірно, щоб людина це спостерігала.

Я працював над інструментом стиснення для інсталятора в 2004 році. Мої тестові дані були деякими інсталяційними файлами Adobe розміром близько 500 Мб або більше.

Після виснажливого запуску компресії та декомпресійного запуску для перевірки цілісності FC / B показав один байт різний.

У цьому байті MSB перекинувся. Я також перевернувся, переживаючи, що у мене божевільна помилка, яка повернеться лише в дуже специфічних умовах - я навіть не знала, з чого почати шукати.

Але щось мені підказало запустити тест ще раз. Я пробіг його і це пройшло. Я створив сценарій для запуску тесту 5 разів за ніч. Вранці всі 5 пройшли.

Тож це було безумовно, космічне бітове перевертання.

Можливо, ви також хочете ознайомитись і з обладнанням Fault Tolerant.

Наприклад, Stratus Technology будує сервери Wintel під назвою ftServer, які мали 2 або 3 "материнські плати" в режимі блокування, порівнюючи результат обчислень. (іноді це робиться і в космічних апаратах).

Сервери Stratus еволюціонували від користувальницьких чіпсетів до блокування кроку на задній плані.

Дуже подібною (але програмною) системою є замок VMWare Fault Tolerance на базі Hypervisor.

Як точка даних, це щойно сталося в нашій збірці:

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

Це виглядає дуже сильно, як трохи перевернутись під час компіляції, у дуже важливому місці у вихідному файлі випадково.

Я не обов'язково кажу, що це був "космічний промінь", але симптом відповідає.