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

Еще раз я был в обзоре дизайна и столкнулся с утверждением, что вероятность того, что конкретный сценарий "меньше, чем риск космических лучей" влияет на программу, и мне пришло в голову, что у меня не было ни малейшего Идея, какова эта вероятность.

"Так как 2 ^-128 - 1 из 340282366920938463463374607431768211456, я думаю, что мы оправдываем свои шансы здесь, даже если эти вычисления не будут в несколько миллиардов... Мы Я полагаю, что это еще больше угрожает космическим лучам."

Правильно ли этот программист? Какова вероятность того, что космический луч ударит по компьютеру и повлияет на выполнение программы?

Ответ 1

От Wikipedia:

Исследования, проведенные IBM в 1990-х годах, показывают, что компьютеры обычно испытывают около одной ошибки, вызванной космическим лучом, на 256 мегабайт оперативной памяти в месяц. ^{[15 ]}

Это означает вероятность 3,7 & times; 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 лет назад.

Ответ 2

По-видимому, это не несущественно. Из этой статьи New Scientist, цитата из патентной заявки Intel:

"Компьютерные сбои, вызванные космическими лучами, произошли и, как ожидается, будут увеличиваться с частотой, поскольку устройства (например, транзисторы) уменьшаются в размерах микросхем. Эта проблема, по прогнозам, станет основным ограничителем надежности компьютера в следующем десятилетии".

Вы можете прочитать полный патент здесь.

Ответ 3

Примечание: этот ответ касается не физики, а об ошибках памяти без модулей памяти ECC. Некоторые из ошибок могут возникать из космоса, а некоторые - из внутреннего пространства рабочего стола.

Существует несколько исследований сбоев памяти ECC на крупных серверных фермах, таких как кластеры CERN и датацентры Google. Аппаратное обеспечение сервера с ECC может обнаруживать и исправлять все одиночные битовые ошибки и обнаруживать много многобитовых ошибок.

Мы можем предположить, что существует множество настольных компьютеров, не относящихся к ECC (и мобильных смартфонов, не относящихся к ECC). Если мы проверим бумаги для исправляемых ошибок ECC (одиночные битфлыпы), мы можем узнать, что уровень памяти нестабилен в памяти без ECC.

Исследование CERN за 2007 год "Целостность данных" : поставщики заявляют "Бит-бит" 10 ^-12 для их памяти модули "," наблюдаемая частота ошибок на 4 порядка ниже ожидаемой ". Для задач с интенсивным использованием данных (8 ГБ/с для чтения в памяти) это означает, что однократное переворачивание может происходить каждую минуту (10 ^-12 поставщиков BER) или один раз в два дня (10 ^-16 BER).
2009 Google "Ошибки DRAM в дикой природе: исследование крупномасштабного поля" говорит, что может быть до 25000-75000 однобитовых FIT за Мбит (неудачи во времени в миллиард часов), что равно 1 - 5 бит в час для 8 ГБ ОЗУ после моих расчетов. Бумага говорит то же самое: "Средние корректируемые коэффициенты ошибок 2000-6000 за ГБ в год".
2012 Sandia report "Обнаружение и исправление безупречной коррупции данных для крупномасштабных высокопроизводительных вычислений" : "двойные битовые сальто считались маловероятными", но при ORNL плотный Cray XT5 они "со скоростью один раз в день для 75 000+ модулей DIMM" даже с ECC. И однобитовые ошибки должны быть выше.

Итак, если программа имеет большой набор данных (несколько GB) или имеет высокую скорость чтения или записи (GB/s или более), и она работает в течение нескольких часов, тогда мы можем ожидать до нескольких тихих бит-флип настольного оборудования. Эта скорость не обнаруживается с помощью memtest, а модули DRAM хороши.

Длинный кластер работает на тысячах компьютеров, отличных от ECC, например, в сетчатых вычислительных сетях BOINC всегда будут возникать ошибки из-за разломов памяти, а также из-за дисковых и сетевых ошибок.

И для более крупных машин (10 тысяч серверов) даже с защитой ECC от однобитовых ошибок, как мы видим в отчете Sandia 2012, каждый день могут быть двубитные флипсы, поэтому у вас не будет шанса на полный запуск -размерную параллельную программу в течение нескольких дней (без регулярной контрольной проверки и перезапуска с последней хорошей контрольной точки в случае двойной ошибки). Огромные машины также получат бит-флипсы в своих кэшах и регистрах процессора (как архитектурные, так и внутренние триггеры чипов, например, в ALU datapath), потому что не все они защищены ECC.

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

Ответ 4

Wikipedia цитирует исследование IBM в 90-е годы предполагают, что "компьютеры обычно испытывают одну ошибку, вызванную космическим лучом, на 256 мегабайт оперативной памяти в месяц". К сожалению, цитата была посвящена статье в Scientific American, которая не давала никаких дальнейших ссылок. Лично я считаю, что число должно быть очень высоким, но, возможно, большинство ошибок памяти, вызванных космическими лучами, не вызывают никаких реальных или заметных проблем.

С другой стороны, люди, говорящие о вероятностях, когда дело доходит до программных сценариев, обычно не имеют понятия, о чем они говорят.

Ответ 5

Ну, космические лучи, по-видимому, вызвали неисправность электроники в автомобилях Toyota, поэтому я бы сказал, что вероятность очень высока:)

Являются ли космические лучи действительно причиной проблем Toyota?

Ответ 6

С помощью ECC вы можете исправить 1-битные ошибки Космических лучей. Чтобы избежать 10% случаев, когда космические лучи приводят к 2-битным ошибкам, ячейки ECC обычно чередуются по микросхемам, поэтому две клетки не находятся рядом друг с другом. Следовательно, событие космического луча, которое влияет на две ячейки, приведет к двум исправляемым ошибкам 1 бит.

Состояние Солнца: (№ по каталогу 816-5053-10 апреля 2002 года)

Вообще говоря, мягкие ошибки космических лучей происходят в памяти DRAM при скорость от 10 до 100 FIT/МБ (1 FIT = 1 сбой устройства в 1 миллиард часов). Таким образом, система с 10 ГБ памяти должна показывать событие ECC каждые 1000 до 10 000 часов, а система со 100 ГБ будет показывать событие каждый От 100 до 1000 часов. Однако это приблизительная оценка, которая изменение в зависимости от эффектов, описанных выше.

Ответ 7

Ошибки памяти реальны, и ECC-память действительно помогает. Правильно реализованная память ECC исправляет ошибки одного бита и обнаруживает двойные битовые ошибки (останавливая систему, если такая ошибка обнаружена.) Вы можете видеть это из того, как регулярно люди жалуются на то, что кажется проблемой программного обеспечения, которая разрешена путем запуска Memtest86 и обнаружение плохой памяти. Конечно, кратковременный отказ, вызванный космическим лучом, отличается от постоянно провальной части памяти, но он имеет отношение к более широкому вопросу о том, насколько вы должны доверять своей памяти, чтобы работать правильно.

Анализ, основанный на резидентном размере 20 МБ, может быть подходящим для тривиальных приложений, но большие системы обычно имеют несколько серверов с большими основными памятью.

Интересная ссылка: http://cr.yp.to/hardware/ecc.html

Ссылка Corsair на странице, к сожалению, кажется мертвой.

Ответ 8

Если программа критически важна для жизни (она будет убивать кого-то, если она терпит неудачу), ее необходимо записать таким образом, чтобы она была либо отказоустойчивой, либо автоматически восстанавливалась после такого сбоя. Все остальные программы, YMMV.

Тойоты - пример. Скажите, что вы будете делать с дроссельным кабелем, но это не программное обеспечение.

См. также http://en.wikipedia.org/wiki/Therac-25

Ответ 9

Я однажды запрограммировал устройства, которые должны были летать в космосе, а затем вы (предположительно, никто никогда не показывал мне никакой бумаги об этом, но, как говорили, были общеизвестны в бизнесе) могли ожидать, что космические лучи вызовут ошибки все время.

Ответ 10

Это реальная проблема, и именно поэтому память ECC используется на серверах и встраиваемых системах. И почему летающие системы отличаются от наземных.

Например, обратите внимание, что компоненты Intel, предназначенные для "встроенных" приложений, обычно добавляют ECC в спецификацию. В Bay Trail для планшета не хватает, так как это сделает память немного дороже и, возможно, медленнее. И если планшет вылетает из программы каждую раз в синюю луну, пользователю все равно. Само по себе программное обеспечение гораздо менее надежное, чем HW. Но для SKU, предназначенных для использования в промышленных машинах и автомобилях, ECC является обязательным. Поскольку здесь мы ожидаем, что SW будет намного более надежным, а ошибки от случайных сбоев будут реальной проблемой.

Системы, сертифицированные по стандарту IEC 61508 и аналогичные стандарты, как правило, имеют как загрузочные тесты, которые проверяют работоспособность всей ОЗУ (ни один бит не застревает в нуле или один), а также обработка ошибок во время выполнения, которая пытается восстановить из-за ошибок, обнаруженных ECC, а также часто и задачи памяти, которые проходят, и постоянно читают и записывают память, чтобы убедиться, что любые ошибки, которые происходят, замечены.

Но для основного программного обеспечения для ПК? Не ахти какое дело. Для долгоживущего сервера? Используйте ECC и обработчик ошибок. Если неисправимая ошибка уничтожает ядро, пусть будет так. Или вы идете параноиком и используете резервную систему с выполнением блокировки, чтобы, если одно ядро получилось повреждено, другое может взять на себя при первом перезагрузке ядра.

Ответ 11

Чаще всего шум может испортить данные. Контрольные суммы используются для борьбы с этим на многих уровнях; в кабеле передачи данных обычно существует бит четности , который перемещается вместе с данными. Этот значительно снижает вероятность коррупции. Затем на уровнях разбора бессмысленные данные обычно игнорируются, поэтому даже если некоторое повреждение прошло мимо бит четности или других контрольных сумм, в большинстве случаев это игнорируется.

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

Но, в конце концов, как говорили другие ответчики, есть случайный бит или байт, который скремблируется, и он оставил на догадку, является ли это значительным байтом или нет. Лучший случайный сценарий, космический луч скремблирует один из пустых бит и не имеет абсолютно никакого эффекта или сбой компьютера (это хорошо, потому что компьютер не может нанести вред); но в худшем случае, я уверен, вы можете себе представить.

Ответ 12

"события космических лучей", как считается, имеют равномерное распределение во многих ответах здесь, это может быть не всегда верно (то есть сверхновые). Хотя "космические лучи" по определению (по крайней мере, согласно Википедии) исходят из космоса, я думаю, что справедливо также включать локальные солнечные бури (aka выброс корональной массы под тем же зонтиком.Я считаю, что это может привести к тому, что несколько бит перевернут в течение короткого промежутка времени, что потенциально может привести к повреждению даже памяти с поддержкой ECC.

Хорошо известно, что солнечные бури могут привести к некоторому хаосу с электрическими системами (например,

Позже "космическое излучение" стало внутренней шуткой на моем рабочем месте. Всякий раз, когда что-то происходит с нашими серверами, и мы не можем найти никаких объяснений, мы в шутку приписываем ошибку "космическому излучению".: -)

Ответ 13

Я испытал это - это не редкость для космических лучей переворачивать один бит, но очень маловероятно, чтобы человек наблюдал это.

В 2004 году я работал над инструментом сжатия для установщика. Мои тестовые данные были некоторыми файлами установки Adobe объемом около 500 МБ или более.

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

Внутри этого байта MSB перевернул. Я также перевернулся, опасаясь, что у меня сумасшедшая ошибка, которая будет только на поверхности в особых условиях - я даже не знал, с чего начать.

Но что-то подсказывало мне снова запустить тест. Я побежал, и он прошел. Я установил script для запуска теста 5 раз за одну ночь. Утром все 5 прошли.

Итак, это был бит-бит космического луча.

Ответ 14

Возможно, вы захотите также взглянуть на аппаратное обеспечение с отказоустойчивостью.

Например, Stratus Technology создает серверы Wintel под названием ftServer, у которого в блокировке есть 2 или 3 "материнские платы", сравнивая результат вычислений. (это иногда делается и в космических аппаратах).

Серверы Stratus превратились из настраиваемого набора микросхем в блокировку на объединительной панели.

Очень похожей (но программной) системой является блокировка отката VMWare, основанная на гипервизоре.

Ответ 15

В качестве точки данных это произошло только в нашей сборке:

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

Это выглядит очень сильно, как бит флип, происходящий во время компиляции, в очень значительном месте в исходном файле случайно.

Я не обязательно говорю, что это был "космический луч", но симптом соответствует.