Stella inattivaStella inattivaStella inattivaStella inattivaStella inattiva
 
Durante il recente 5° Workshop di BOINC si è accennato al nuovo sistema di crediti che D.Anderson e il suo staff hanno in mente. Circa una settimana dopo è apparso sul sito di BOINC il documento che spiega nel dettaglio il loro progetto.
Riportiamo qui la traduzione integrale del documento.
.
 
 
 
Picco dei FLOPS ed efficienza

BOINC fa una stima del picco di FLOPS per ogni tipo processore:
•    per le CPU verrà considerato il risultato del test Whetstone
•    per le GPU si utilizza una formula data dal costruttore/fornitore

In ogni caso vi sono altri fattori che influenzano le performance delle applicazioni. Per esempio la quantità di memoria che utilizzano oppure la stessa velocità della RAM del computer (il cui valore non si riflette nei risultati del test Whetstone). Quindi può accadere che la stessa WU impieghi lo stesso tempo CPU sia su un PC da 1 GFLOPS sia su uno da 10 GFLOPS. L’efficienza di una applicazione su un determinato PC è il rapporto tra FLOPS reali e picco di FLOPS.
Le GPU hanno solitamente un picco di FLOPS molto più alto delle CPU (50-100 volte superiore) anche se l’efficienza delle applicazioni è statisticamente inferiore (valori tipici: 10% per le GPU, 50% per le CPU).


Obiettivi del sistema di crediti

Alcuni possibili obiettivi della progettazione di un sistema di crediti:
•    neutralità dell’hardware: WU simili dovrebbero ricevere un simile ammontare di crediti indipendentemente da quale processore o GPU sia stato utilizzato.
•    neutralità del progetto: per un dato processore i diversi progetti dovrebbero garantire circa lo stesso ammontare di crediti giornalieri.

E’ semplice dimostrare che entrambi gli obiettivi si possono raggiungere simultaneamente.


Il primo tipo di sistema (Peak-FLOPS based)

All’inizio il sistema di crediti di BOINC definiva i “claimed credits” (crediti pretesi) come:

C1 = H x J = (valore test Whetstone) x (tempo CPU)

Vi erano poi diversi schemi di calcolo dei “granted credits” (crediti distribuiti) in base alla media o al valore minimo dei crediti pretesi per le diverse copie delle WU elaborate e consegnate.
Ora invece il sistema di crediti viene definito "Peak-FLOPS-based" perché è basato sulle performance di picco della CPU. Il problema di un sistema del genere è che, per una data versione dell’applicazione, l’efficienza può variare notevolmente tra i vari PC. Ad esempio un PC da 10 GFLOPS pretenderà dieci volte l’ammontare di crediti rispetto a un PC da 1 GFLOPS e il suo proprietario non sarebbe certo contento di ricevere solo un decimo dei crediti richiesti.

C’è di più: i crediti distribuiti ad un certo PC per una serie di WU identiche può variare moltissimo in funzione dei PC che hanno ricevuto quelle stesse WU nel caso di verifica incrociata dei risultati (replicazione iniziale > 1 e quorum > 1).


Il secondo tipo di sistema (Actual-FLOPS based)

In seguito si è passati ad un sistema la cui filosofia è che i crediti dovrebbero essere proporzionali ai FLOPS realmente realizzabili da una data applicazione su un dato PC. Sono state quindi sviluppate delle API che permettono all’applicazione di riportare questo valore nelle WU consegnate. Questo tipo di approccio è definito “Actual-FLOPS based”.

Le applicazioni di SETI@home permettono già questo tipo di calcolo dei FLOPS. Loro hanno adottato questo sistema applicando poi un moltiplicatore (fattore di scala) in modo che i crediti medi per WU siano gli stessi del sistema precedente.
Non tutti i progetti però possono calcolare i FLOPS delle loro applicazioni. Attualmente SETI@home pubblica i suoi valori dei crediti medi per secondo CPU e gli altri possono continuare ad utilizzare il vecchio sistema mediante applicazione di un ulteriore fattore di scala che li renda simili.

Questo sistema presenta parecchi problemi:
•    non considera le GPU
•    i progetti che non possono calcolare i FLOPS hanno comunque dei problemi riguardo alla neutralità dell’hardware
•    non contrasta in alcun modo chi bara sui crediti in caso di replicazione iniziale unitaria (risultato in base ad un’unica WU senza verifica incrociata)


Obiettivi del nuovo (terzo) tipo di sistema

•    funzionamento in automatico: i vari progetti non dovranno modificare il codice o le impostazioni
•    neutralità dell’hardware
•    limitata neutralità del progetto: i diversi progetti dovrebbero garantire tutti più o meno lo stesso ammontare di crediti per ora CPU calcolato sulla media dei PC degli utenti. I progetti che dispongono di applicazioni per GPU dovrebbero garantire i crediti in proporzione all’efficienza di queste applicazioni; questo poi significa che  applicazioni più efficienti garantiranno più crediti e questo è giusto)


Peak FLOPS Count (PFC)

Questo sistema utilizza lo stesso approccio “Peak-FLOPS based” ma implementato in modo diverso.
Quando una WU (chiamata anche J da Job) viene inviata ad un PC, lo Scheduler specifica il parametro usage(J,D) e cioè l’utilizzo delle risorse di calcolo da parte di J e D è il numero di queste risorse (numero di core CPU e di GPU, possibilmente frazionale). Già ora questi valori appaiono nella colonna “status” del BOINC manager.
Se la WU viene terminata in un tempo T allora si calcola il parametro peak_flop_count(J) o PFC(J) come:

PFC(J) = T x Somma(usage(J, D) * peak_flop_rate(D))

dove la somma è estesa a tutte le risorse D (mentre ipotizzo che peak_flop_rate(D) sia l’efficienza di D espressa come rapporto tra i FLOPS reali e quelli di picco, n.d.r.)
 
Note:
•    viene utilizzato il valore del tempo effettivamente trascorso (“elapsed time”) invece di quello del tempo impiegato dalla risorsa (“CPU time”). Se una WU utilizza in modo inefficiente una risorsa (es. se l’applicazione effettua molte operazioni di I/O con l’hard disk), questo non si rifletterà sul PFC. Questa è una cosa giusta; il concetto chiave è che BOINC riserva la risorsa per la WU indipendentemente dal fatto che l’applicazione la utilizzi poi in modo efficiente o meno.
•    usage(J,D) potrebbe non essere accurato. Ad esempio una WU per GPU potrebbe utilizzare più o meno CPU di quello che ritiene lo Scheduler. Dovesse essere necessario verrà implementato un sistema di valutazione dinamica (in tempo reale) dell’utilizzo della CPU da parte del PC. Al momento comunque verrà utilizzata la stima dello Scheduler.

I crediti garantiti per una WU saranno proporzionali al PFC in base a diversi criteri di normalizzazione.


Normalizzazione di tipo Cross-version

Se una certa applicazione ha diverse versioni (ad esempio una per CPU e una per GPU) allora i crediti garantiti per le WU saranno aggiustati in modo che la media sia la stessa per tutte le versioni. L’aggiustamento sarà sempre al ribasso: centralmente (sotto responsabilità del progetto BOINC)  verranno calcolate le medie PFCmedio(V) del PFC per ogni versione V dell’applicazione e ne verrà calcolato il valore minimo X. In seguito si calcolerà il fattore di scala S per una WU relativa ad una certa versione dell’applicazione:

S(V) = X / PFCmedio(V)

I crediti assegnati ad una WU si indicheranno infine con il nome di "Version-Normalized Peak FLOPS Count", o VNPFC(J), e saranno pari a:

VNPFC(J) = PFC(J) x S(V) = PFC(J) x (X / PFCmedio(V) )

Note:
•    è evidente che se una applicazione ha solo la versione per CPU allora X= PFCmedio(V) e S(V)=1 e VNPFC(J) = PFC(J)
•    la situazione abbastanza comune in cui l’applicazione per GPU è molto meno efficiente di quella per CPU porta questo meccanismo di calcolo, in un certo senso, ad avvicinarsi alla filosofia degli "Actual FLOPS" in quanto i crediti vengono garantiti basandosi sulla versione più efficiente dell’applicazione. Non è proprio la stessa cosa in quanto anche la versione più efficiente potrebbe non essere efficiente al 100%.
•    vi sono due cause di variabilità di PFC(V): variazioni nell’efficienza dei PC che elaborano le WU e variazioni nella pesantezza delle WU stesse. Se si avesse una stima a priori della pesantezza delle WU si potrebbe normalizzare PFC(J) in base a questa e far quindi convergere più rapidamente il valore di PFCmean(V).
•    si potrebbe anche stimare la pesantezza delle WU a posteriori (un conteggio delle iterazioni fatto dall’applicazione stessa) ma questo introdurrebbe dei rischi perché darebbe a qualcuno nuove possibilità di barare, quindi probabilmente non verrà implementato.


Normalizzazione di tipo Cross-project

Se un’applicazione ha entrambe le versioni per CPU e GPU allora il meccanismo di normalizzazione appena descritto utilizza la versione per CPU come base per un meccanismo di verifica di coerenza: si vanno a limitare i crediti garantiti per le WU elaborate dalla GPU.
Si supponga però che un progetto abbia solo un’applicazione per GPU e che quindi non ci sia la versione per CPU con cui fare il confronto. Se si garantissero i crediti basandosi solo sulla velocità di picco della GPU allora il progetto elargirebbe molti più crediti per ora GPU di quanto facciano gli altri progetti: si violerebbe la limitata neutralità del progetto.

Una soluzione possibile: per ogni versione V dell’applicazione per GPU (o meglio per ogni GPU) verrà ancora utilizzato S(V) ma questo sarà la media dei fattori di scala realizzati dagli altri progetti per quella GPU. Questo fattore sarà fornito dal server centrale di BOINC.

Note:
•    i progetti periodicamente faranno girare uno script che aggiornerà i fattori di scaola S(V)
•    piuttosto che basarsi sulle singole GPU verranno utilizzate delle classi in quanto, ad esempio, l’efficienza media del pacchetto CUDA 2.3 è superiore a quella del CUDA 2.1.
•    inizialmente verranno presi in considerazione i fattori di scala ottenuti dai grandi progetti che hanno applicazioni sia per CPU che per GPU (es. SETI@home). Eventualmente si potrebbe fare una media tra i vari progetti pesata sulla quantità di WU elaborate.
 
 
Normalizzazione in base all’host (PC)

Assumendo che agli host vengono inviate WU per una data applicazione in modo uniforme, allora per quella applicazione gli host dovrebbero anche ricevere lo stesso ammontare medio di crediti per WU. Per assicurarsi che questo avvenga, per ogni applicazione A viene calcolata una media VNPFCmedio(A), e per ogni host viene poi calcolata la VNPFCmedio(H, A) su una particolare applicazione. I FLOPS reclamati per WU saranno quindi:

F = VNPFC(J) x (VNPFCmedio(A) / VNPFCmedio(H, A))

e i crediti reclamati saranno (ricordando che un giorno ha 86400 secondi):

C = F x 100 / 86400e9

Vi sono però alcuni casi in cui agli host non vengono inviate le WU in modo uniforme:
•    progetti che inviano ai PC più lenti delle WU di dimensioni inferiori
•    GPUGrid segue uno schema che prevede l’invio di WU diverse in funzione dei core della GPU

In questi casi la media dei crediti per WU dovrebbe essere diversa tra diversi host. Questo si può realizzare calcolando VNPFCmean come media dei singoli valori divisi per WU.rsc_fpops_est che è un valore stimato a priori (non c’è ragione per cui questo non possa essere fatto comunque).

Note:
•    il meccanismo di normalizzazione in base all’host riduce i crediti richiesti dai PC che sono meno efficienti della media, li aumenta per quelli che sono più efficienti della media
•    VNPFCmean è mediato sulle WU e non sui PC
 
 
Calcolo delle medie

Bisogna fare molta attenzione nel calcolo delle medie perché:

•    i valori di cui si calcola la media potrebbero variare nel tempo (per es. la pesantezza delle WU potrebbe cambiare, l’efficienza dell’applicazione potrebbe essere diversa da versione a versione) ed è necessario tenere in considerazione questi cambiamenti
•    uno dei valori considerati nel calcolo potrebbe essere non in linea con gli altri e non si può permettere che influenzi la media
•    le medie dovrebbero essere pesate sulla dimensione delle WU

In più il database delle medie deve essere aggiornato al variare delle quantità, cosa che il sistema attuale non precede.
 
 
Replicazione iniziale e metodi per barare

La normalizzazione in base all’host disincentiva il tentativo di barare richiedendo un ammontare di crediti eccessivo (ad es. falsificando i benchmark o il tempo di elaborazione). Una richiesta esagerata farà aumentare VNPFC*(H,A) causando di conseguenza una riscalatura verso il basso delle richieste successive (la media si alza). Questo fa si che non sia necessario prevedere dei particolari meccanismi di controllo in caso di replicazione iniziale unitaria: i crediti garantiti saranno uguali a quelli richiesti.

Per le WU con replicazione iniziale maggiore, i crediti garantiti dovrebbero essere pari al minimo di quelli richiesti per i risultati validi (questo metodo è migliore dell’utilizzo della media dei crediti richiesti soprattutto nel caso di fenomeni di Cherry-picking, spiegati qui di seguito).

In ogni caso esistono ancora alcuni modi (salvo novità) possibili per barare:
•    barare su un’unica WU (One-time cheat) richiedendo ad esempio un ammontare di crediti elevatissimo. Questa eventualità si può limitare accettando per VNPFC(J) solo valori inferiori ad un multiplo di VNPFCmedio(A)
•    Cherry-picking: si supponga che una applicazione elabora due tipi di WU, una che dura un secondo e una che dura un’ora rispettivamente. Il client può riconoscere quale sta elaborando (ad es. facendola girare per due secondi e controllando se è terminata) e potrebbe rifiutare sistematicamente quelle del secondo tipo più lunghe. Il suo VNPFCmedio(H, A) diminuirebbe molto velocemente e di conseguenza farebbe guadagnare molti più crediti di quello che ricevono gli altri PC! Una contromisura potrebbe essere quella di resettare VNPFCmedio(H, A) al valore di VNPFCmedio(A) per tutte le applicazioni.
 


Accedi per commentare