Stima della probabilità di errore hardware

Supponiamo che esegua un calcolo di supercomputer su 100k core per 4 ore su http://www.nersc.gov/users/computational-systems/edison/configuration , scambiando circa 4 PB di dati sulla rete ed eseguendo circa 4 TB di I / O. Il calcolo è tutto intero, quindi i risultati sono giusti o sbagliati (nessun errore numerico intermedio).

Supponendo che il codice sia corretto, vorrei stimare la probabilità che il calcolo sia errato a causa di un errore hardware. Qual è un buon modo per farlo? Ci sono buone fonti per i numeri richiesti per fare una stima del genere?

Hai esaminato i vari rapporti exascale che sono usciti? I fallimenti duri non sono una preoccupazione significativa oggi - certo, accadono, ma la loro frequenza non è sufficientemente alta da causare gravi preoccupazioni. Ma si stima che siano sufficientemente frequenti sui sistemi exascale con o più core che i codici devono essere preparati per reagire in modo appropriato. Credo che questi problemi siano stati esposti nelle relazioni sulle tabelle di marcia verso l'exascale.$O(10^8)$

Il mio ricordo è che tra le varie modalità di errore, i capovolgimenti a bit singolo in memoria o sui core del processore non erano le preoccupazioni più significative. Piuttosto, si sono verificati interi nodi in declino, ad esempio a causa di un errore del disco, guasti del sistema operativo, ecc. Gli attuali progetti exascale richiedono quindi tutti il ​​checkpoint periodico dei codici nella RAM flash, preferibilmente trasmettendo i dati del checkpoint fuori nodo. I codici dovranno quindi essere in grado di riavviarsi al volo da uno stato precedentemente salvato se il sistema rileva che un nodo è scomparso, sostituendo questo nodo con un nodo di avvio a caldo in altre parti del sistema.

Immagino che inizi raccogliendo i tassi di errore dei componenti, come DRAM, come questa ricerca di Google sugli errori DRAM in the Wild: uno studio sul campo su larga scala Hanno trovato una probabilità dell'1% di ottenere un errore non correggibile all'anno.

Non sono sicuro che sia quello che ti interessa. Sarei più interessato agli errori non rilevabili. Errori tali da non rilevare i tipici metodi di controllo degli errori Ad esempio, quando si inviano pacchetti sopra l'ottica, sono accompagnati da una sorta di CRC, che consente una piccola possibilità di errore.

AGGIORNAMENTO: questo documento Architectures for Online Error Detection and Recovery in Multicore Processors parla di un'affidabile architettura multicore, ma copre anche diversi aspetti dell'affidabilità del sistema e dispone di bibliografia

Ci sono buone fonti per i numeri richiesti per fare una stima del genere?

Potresti provare a chiedere agli amministratori del cluster su cui stai elaborando. Immagino che, nell'ambito del loro processo di validazione, abbiano affrontato il problema di stimare la probabilità di errori hardware.

Sembra epico. Se nessuno ha fatto questo esperimento, potresti prendere in considerazione l'esecuzione di 100k core separati facendo qualcosa di simile al rehashing di un input sha1 più e più volte, vedendo qual è il tasso di errore. (Sospetto incommensurabile), da lì fanno lo stesso, ma li fanno scambiare i risultati della catena hash ogni tanto per ottenere i tassi di errore della rete. Immagino che anche questo sia molto piccolo, ma sospetto che tu possa averne almeno un paio usando il tuo super cluster in poche ore :)

Questo approccio assicura che ogni calcolo sia corretto, poiché l'hashing è estremamente sensibile agli swap a bit singolo, mentre anche un solo calcolo intero potrebbe nascondere errori nei rami, vale a dire che l'intero calcolo non sarebbe ellittico su ogni stato di memoria consecutivo.

Ho lavorato su un modo per garantire che il codice sia stato eseguito correttamente da un cluster esterno la cui motivazione è imbrogliare inviando risultati falsi. La soluzione su cui mi sono converto è l'integrazione dell'hash nel calcolo con una certa frequenza che rende i trucchi meno efficienti del lavoro.