Скажем, я выполняю вычисления на суперкомпьютере на 100 000 ядер в течение 4 часов на http://www.nersc.gov/users/computational-systems/edison/configuration , обмениваясь по сети примерно 4 ПБ данных и выполняя около 4 ТБ I / О. Все вычисления являются целочисленными, поэтому результаты либо правильные, либо неправильные (без промежуточных числовых ошибок).
Предполагая, что код правильный, я хотел бы оценить вероятность того, что вычисления неверны из-за аппаратного сбоя. Какой хороший способ пойти по этому поводу? Есть ли хорошие источники для чисел, необходимых для такой оценки?
error-estimation
Джеффри Ирвинг
источник
источник
Ответы:
Вы смотрели на различные отчеты exascale, которые вышли? Сегодняшние неудачи не являются серьезной проблемой - конечно, они случаются, но их частота не достаточно высока, чтобы вызвать серьезное беспокойство. Но, по оценкам, они достаточно часты в системах с избыточным количеством или более ядер, которые необходимо подготовить для правильного реагирования кодов. Я считаю, что эти вопросы были изложены в докладах о дорожных картах в направлении exascale.O ( 108)
Насколько я помню, среди различных режимов сбоев, однобитовые перевороты в памяти или на ядрах процессора не были самыми важными проблемами. Скорее, это были целые узлы, выходящие из строя, например, из-за сбоя диска, сбоев операционной системы и т. Д. Таким образом, все существующие проекты масштабирования требуют периодической контрольной точки кодирования во флэш-ОЗУ, предпочтительно передавая данные контрольной точки вне узла. Коды затем должны будут иметь возможность перезапуска на лету из ранее сохраненного состояния, если система обнаружит, что один узел исчез, заменив этот узел узлом горячего запуска в другом месте системы.
источник
Я предполагаю, что вы начнете со сбора данных об ошибках компонентов, таких как DRAM, как это исследование Google по ошибкам DRAM в дикой природе: крупномасштабное полевое исследование. Они обнаружили, что ~ 1% вероятности получить одну неисправимую ошибку в год.
Я не уверен, если это то, что вам интересно. Я был бы более заинтересован в необнаружимых ошибках. Ошибки такие, что типичные методы проверки ошибок не будут обнаружены. Например, когда вы отправляете пакеты по оптике, они сопровождаются своего рода CRC, который дает небольшую вероятность проскальзывания ошибки.
ОБНОВЛЕНИЕ: эта статья « Архитектуры для онлайн обнаружения и восстановления ошибок в многоядерных процессорах» рассказывает о надежной многоядерной архитектуре, но они также охватывают различные аспекты надежности системы и имеют библиографию
источник
Вы можете попытаться спросить администраторов кластера, на котором вы работаете. Я полагаю, что в рамках процесса проверки они столкнулись с проблемой оценки вероятности аппаратных ошибок.
источник
Звучит эпично. Если никто не проводил этот эксперимент, вы можете рассмотреть возможность запуска 100k отдельных ядер, делая что-то вроде перефразирования ввода sha1 снова и снова, чтобы увидеть, какова частота ошибок. (Неизмеримо, я подозреваю), оттуда делают то же самое, но заставляют их время от времени обмениваться результатами цепочки хеширования, чтобы получить частоту ошибок в вашей сети. Я думаю, что это тоже очень мало, но я подозреваю, что вы можете получить хотя бы пару, используя свой суперскоп, за несколько часов :)
Такой подход гарантирует, что каждый вычисления правильны, так как хеширование чрезвычайно чувствительно к однобитным перестановкам, в то время как даже целочисленные вычисления могут скрывать ошибки в ветвях, то есть все вычисления не будут эллиптическими в каждом последующем состоянии памяти.
Я работал над тем, чтобы гарантировать, что внешний кластер правильно выполнил код, мотивация которого состоит в том, чтобы обманывать, отправляя поддельные результаты. Решение, с которым я столкнулся, заключается в интеграции хеша в вычисления с некоторой частотой, которая делает мошенничество менее эффективным, чем выполнение работы.
источник