Оценка вероятности аппаратной ошибки

13

Скажем, я выполняю вычисления на суперкомпьютере на 100 000 ядер в течение 4 часов на http://www.nersc.gov/users/computational-systems/edison/configuration , обмениваясь по сети примерно 4 ПБ данных и выполняя около 4 ТБ I / О. Все вычисления являются целочисленными, поэтому результаты либо правильные, либо неправильные (без промежуточных числовых ошибок).

Предполагая, что код правильный, я хотел бы оценить вероятность того, что вычисления неверны из-за аппаратного сбоя. Какой хороший способ пойти по этому поводу? Есть ли хорошие источники для чисел, необходимых для такой оценки?

Джеффри Ирвинг
источник
Я полагаю, что результаты процессора / оперативной памяти действительно стабильны по сравнению с сетевыми характеристиками и диском.
Meawoppl

Ответы:

5

Вы смотрели на различные отчеты exascale, которые вышли? Сегодняшние неудачи не являются серьезной проблемой - конечно, они случаются, но их частота не достаточно высока, чтобы вызвать серьезное беспокойство. Но, по оценкам, они достаточно часты в системах с избыточным количеством или более ядер, которые необходимо подготовить для правильного реагирования кодов. Я считаю, что эти вопросы были изложены в докладах о дорожных картах в направлении exascale.О(108)

Насколько я помню, среди различных режимов сбоев, однобитовые перевороты в памяти или на ядрах процессора не были самыми важными проблемами. Скорее, это были целые узлы, выходящие из строя, например, из-за сбоя диска, сбоев операционной системы и т. Д. Таким образом, все существующие проекты масштабирования требуют периодической контрольной точки кодирования во флэш-ОЗУ, предпочтительно передавая данные контрольной точки вне узла. Коды затем должны будут иметь возможность перезапуска на лету из ранее сохраненного состояния, если система обнаружит, что один узел исчез, заменив этот узел узлом горячего запуска в другом месте системы.

Вольфганг Бангерт
источник
Это звучит как то, что мне нужно. Вы имеете в виду конкретные примеры?
Джеффри Ирвинг
1
Я бы посмотрел, есть ли среди различных отчетов DoE что-нибудь интересное для вас. Я полагаю, вы также знаете о exascale.org ? Там должно быть много, чтобы прочитать там для вас.
Вольфганг Бангерт
1
Джефф, исчерпывающий отчет об исследованиях предоставлен Питером Когге и доступен онлайн . Посмотрите на любые случаи слова устойчивости. Тем не менее, я могу указать вам на несколько человек в NERSC, которые могут иметь более конкретную информацию об этой машине.
Арон Ахмадиа
@AronAhmadia: Спасибо, этот документ выглядит великолепно. Я принимаю этот ответ, так как он должен охватывать больше классов ошибок, которые меня интересуют.
Джеффри Ирвинг
@Wolfgang: Это напоминает мне о моих временах холодной войны, когда ракеты Minuteman были запрограммированы с контрольными точками, так что, если поблизости возникла нейтронная вспышка, вызывающая мгновенное отключение процессора, она могла перезапуститься с самой последней контрольной точки. Если он проходил контрольно-пропускные пункты в подходящее время, его называли «защищенным от перезапуска».
Майк Данлавей
9

Я предполагаю, что вы начнете со сбора данных об ошибках компонентов, таких как DRAM, как это исследование Google по ошибкам DRAM в дикой природе: крупномасштабное полевое исследование. Они обнаружили, что ~ 1% вероятности получить одну неисправимую ошибку в год.

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

ОБНОВЛЕНИЕ: эта статья « Архитектуры для онлайн обнаружения и восстановления ошибок в многоядерных процессорах» рассказывает о надежной многоядерной архитектуре, но они также охватывают различные аспекты надежности системы и имеют библиографию

Аксакал почти наверняка бинарный
источник
Отличная учеба. Это подтверждает, что интуиция, старая, горячая, часто используемая, почти полный баран менее надежна. Я несколько удивлен, что у поставщика нет особых сбоев или вообще худших архитектур.
Meawoppl
3

Есть ли хорошие источники для чисел, необходимых для такой оценки?

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

Сумед Джоши
источник
Благодарность! Задним числом это очевидно, но мне это не пришло в голову.
Джеффри Ирвинг
2

Звучит эпично. Если никто не проводил этот эксперимент, вы можете рассмотреть возможность запуска 100k отдельных ядер, делая что-то вроде перефразирования ввода sha1 снова и снова, чтобы увидеть, какова частота ошибок. (Неизмеримо, я подозреваю), оттуда делают то же самое, но заставляют их время от времени обмениваться результатами цепочки хеширования, чтобы получить частоту ошибок в вашей сети. Я думаю, что это тоже очень мало, но я подозреваю, что вы можете получить хотя бы пару, используя свой суперскоп, за несколько часов :)

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

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

meawoppl
источник
2
К сожалению, вряд ли ваша схема майнинга биткойнов будет одобрена. :)
Джеффри Ирвинг
Ти хи хи. Это просто доказательство работы на самом деле. : P
meawoppl