Космические лучи: какова вероятность того, что они повлияют на программу? - PullRequest
514 голосов
/ 06 апреля 2010

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

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

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

Ответы [ 15 ]

294 голосов
/ 06 апреля 2010

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

Исследования, проведенные 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 лет назад.

86 голосов
/ 06 апреля 2010

Видимо, немаловажно. Начиная с этой статьи нового ученого , цитата из заявки на патент Intel:

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

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

48 голосов
/ 11 мая 2014

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

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

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

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

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

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

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

30 голосов
/ 06 апреля 2010

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

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

29 голосов
/ 06 апреля 2010

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

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

23 голосов
/ 10 апреля 2011

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

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

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

17 голосов
/ 06 апреля 2010

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

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

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

К сожалению, ссылка на Corsair на странице устарела.

13 голосов
/ 06 ноября 2014

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

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

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

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

13 голосов
/ 06 апреля 2010

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

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

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

11 голосов
/ 06 апреля 2010

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

...