Оцінка ймовірності апаратної помилки

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

Припускаючи, що код правильний, я хотів би оцінити ймовірність того, що обчислення невірно через несправність обладнання. Який хороший шлях для цього? Чи є хороші джерела для кількості, необхідної для такої оцінки?

$O(10^8)$

Моє згадування полягає в тому, що серед різних режимів відмов одиночні біти фліп в пам'яті або на процесорних ядрах не були найбільш важливими проблемами. Скоріше, цілі вузли знижувалися, наприклад, через збій диска, несправності операційної системи тощо. Поточні конструкції екскавальної шкали тому вимагають періодичної контрольної точки кодів у флеш-пам’яті, бажано передаючи дані про контрольну точку від вузла. Потім коди повинні мати змогу перезапуститись на льоту з раніше збереженого стану, якщо система стикається з тим, що один вузол зник, замінивши цей вузол вузлом гарячого запуску в іншому місці системи.

Я думаю, ви починаєте зі збирання частоти помилок таких компонентів, як DRAM, як це дослідження Google щодо помилок DRAM в дикій природі: велике масштабне польове дослідження. Вони виявили ~ 1% шансу отримати одну непоправлену помилку на рік.

Я не впевнений, що саме це вам цікаво. Мене більше зацікавлять невизначені помилки. Помилки такі, що типові методи перевірки помилок не виявлять. Наприклад, коли ви надсилаєте пакети через оптику, вони супроводжуються деяким КРС, що дозволяє мати невеликий шанс проскочити помилку.

ОНОВЛЕННЯ: у цьому документі Архітектури виявлення та відновлення помилок в Інтернеті в багатоядерних процесорах розповідається про надійну багатоядерну архітектуру, але вони також охоплюють різні аспекти надійності системи та мають бібліографію.

Чи є хороші джерела для кількості, необхідної для такої оцінки?

Ви можете спробувати попросити адміністраторів кластеру, на якому ви здійснюєте обчислення. Я уявляю, що в процесі їх перевірки вони зіткнулися з проблемою оцінки ймовірності апаратних помилок.

Звучить епічно. Якщо ніхто не зробив цього експерименту, ви можете розглянути можливість виконання 100k окремих ядер, роблячи щось на кшталт повторного повторного введення ша1 вводу знову і знову, бачачи, що таке показник помилок. (Я не підозрюю), звідти робимо те ж саме, але пропонуємо їм торгувати результатами хеш-ланцюгу так часто, щоб отримати ваші показники помилок у мережі. Я думаю, це також дуже мало, але я підозрюю, що ти можеш отримати хоча б пару за допомогою свого суперкластера протягом кількох годин :)

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

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