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

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

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

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

Из Википедии :

Исследования, проведенные IBM в 1990-х годах, показывают, что компьютеры обычно испытывают примерно одну ошибку, вызванную космическими лучами, на 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 2009 года «Ошибки DRAM в дикой природе: крупномасштабное полевое исследование» говорится, что может быть до 25000-75000 однобитных FIT на Мбит ( сбои во времени на миллиард часов ), что равно 1 - 5 битам. ошибок в час для 8ГБ оперативной памяти после моих расчетов. В документе говорится то же самое: « означает исправимые ошибки в 2000–6000 за ГБ в год ».

• Отчет Sandia 2012 года «Обнаружение и исправление искажения данных без вывода сообщений для крупномасштабных высокопроизводительных вычислений» : «двухбитные перевороты считались маловероятными», но в плотном Cray XT5 ORNL они «со скоростью один в день для 75 000+ DIMM» с ECC. И однобитовые ошибки должны быть выше.

Таким образом, если программа имеет большой набор данных (несколько ГБ) или имеет высокую скорость чтения или записи в память (ГБ / с или более) и работает в течение нескольких часов, то мы можем ожидать до нескольких тихих переключений битов на настольном оборудовании. Эта скорость не обнаруживается в memtest, и модули DRAM хороши.

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

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

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

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

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

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

Действительно ли космические лучи вызывают беду у Тойоты?

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

Sun заявляет: (Часть № 816-5053-10 апреля 2002 года)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Около 10 лет назад я сидел рядом с другим парнем, мы сидели с каждым из наших ноутбуков, это было в период с довольно «штормовой» солнечной погодой (сидя в Арктике, мы могли наблюдать это косвенно - множество северных сияний увидимся). Внезапно - в один и тот же момент - оба наших ноутбука рухнули. Он работал под управлением OS X, а я - под Linux. Никто из нас не привык к сбоям ноутбуков - это довольно редко встречается в Linux и OS X. Общие ошибки в программном обеспечении могут быть более или менее исключены, поскольку мы работали в разных ОС (и этого не произошло во время прыжка). второй). Я приписал это событие "космическому излучению".

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

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

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

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

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

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

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

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

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

Так что это определенно был космический луч.

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

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

Серверы 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  - ^

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

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