Szacowanie prawdopodobieństwa błędu sprzętowego

Powiedzmy, że prowadzę obliczenia superkomputerowe na rdzeniach 100k przez 4 godziny na http://www.nersc.gov/users/computational-systems/edison/configuration , wymieniając około 4 PB danych przez sieć i wykonując około 4 TB I / O. Wszystkie obliczenia są liczbami całkowitymi, więc wyniki są poprawne lub niepoprawne (bez pośrednich błędów numerycznych).

Zakładając, że kod jest poprawny, chciałbym oszacować prawdopodobieństwo, że obliczenia są nieprawidłowe z powodu awarii sprzętu. Jak to zrobić? Czy istnieją dobre źródła liczb wymaganych do dokonania takiego oszacowania?

Czy spojrzałeś na różne opublikowane raporty eksaskalowe? Trudne awarie nie są dziś istotnym problemem - na pewno się zdarzają, ale ich częstotliwość nie jest wystarczająco wysoka, aby spowodować poważne zmartwienie. Szacuje się jednak, że są one wystarczająco częste w systemach egzaskalowych z lub większą liczbą rdzeni, aby kody mogły być odpowiednio przygotowane, aby odpowiednio zareagować. Uważam, że kwestie te zostały określone w sprawozdaniach dotyczących planów działania w kierunku egzaskalii.$O(10^8)$

Przypominam sobie, że wśród różnych trybów awarii pojedyncze bity w pamięci lub na rdzeniach procesorów nie były najważniejszymi problemami. Raczej spadały całe węzły, np. Z powodu awarii dysku, błędów systemu operacyjnego itp. Obecne projekty eksaskalowe wymagają zatem okresowego sprawdzania kodów do pamięci flash RAM, najlepiej przesyłając dane punktu kontrolnego poza węzłem. Kody będą wtedy musiały być w stanie zrestartować się w locie z wcześniej zapisanego stanu, jeśli system napotka, że ​​jeden węzeł zniknął, zastępując ten węzeł węzłem szybkiego startu w innym miejscu w systemie.

Wydaje mi się, że zaczynasz od zbierania wskaźników błędów komponentów, takich jak DRAM, takich jak badanie Google dotyczące błędów pamięci DRAM w środowisku naturalnym: duże badanie terenowe Okazało się, że ~ 1% szansa na uzyskanie jednego błędu nie do naprawienia rocznie.

Nie jestem pewien, czy to jest to, co cię interesuje. Byłbym bardziej zainteresowany niewykrywalnymi błędami. Błędy, których typowe metody sprawdzania błędów nie wykryłyby. Na przykład, gdy wysyłasz pakiety za pośrednictwem optyki, towarzyszy im coś w rodzaju CRC, co pozwala na małą szansę prześlizgnięcia się błędu.

AKTUALIZACJA: w tym artykule Architektury online do wykrywania i odzyskiwania błędów w procesorach wielordzeniowych mówi się o niezawodnej architekturze wielordzeniowej, ale obejmują one także różne aspekty niezawodności systemu i mają bibliografię

Czy istnieją dobre źródła liczb wymaganych do dokonania takiego oszacowania?

Możesz spróbować zapytać administratorów klastra, na którym pracujesz. Wyobrażam sobie, że w ramach procesu sprawdzania poprawności zmierzyli się z problemem oszacowania prawdopodobieństwa błędów sprzętowych.

Brzmi niesamowicie. Jeśli nikt nie przeprowadził tego eksperymentu, możesz rozważyć uruchomienie 100 tys. Osobnych rdzeni, wykonując coś w rodzaju ciągłego powtarzania sha1, sprawdzając, jaki jest poziom błędu. (Podejrzewam, że nie do zmierzenia), stamtąd rób to samo, ale niech tak często wymieniają wyniki łańcucha mieszania, aby uzyskać wskaźniki błędów sieci. Wydaje mi się, że to też jest bardzo małe, ale podejrzewam, że możesz zdobyć co najmniej parę za pomocą supergromady w ciągu kilku godzin :)

Takie podejście zapewnia, że każde obliczenie jest prawidłowe, ponieważ haszowanie jest wyjątkowo wrażliwe na zamiany jednobitowe, podczas gdy nawet obliczenie tylko liczby całkowitej może ukryć błędy w gałęziach, tj. Całe obliczenie nie byłoby eliptyczne w każdym kolejnym stanie pamięci.

Pracowałem nad sposobem, aby zapewnić poprawne działanie kodu przez zewnętrzny klaster, którego motywacją jest oszukiwanie poprzez przesyłanie fałszywych wyników. Rozwiązaniem, na którym się skupiłem, jest włączenie skrótu do obliczeń z pewną częstotliwością, która sprawia, że ​​oszukiwanie jest mniej wydajne niż wykonywanie pracy.