Considerazioni su un utilizzo ottimale dei BOINC Multipli.
Dopo molte prove(e molti errori) posso aggiungere alcune informazioni aggiuntive per un corretto uso dei BOINC multipli.
Dopo aver creato il secondo, terzo .... client secondo le specifiche già riportate, si tratta di connettere il client, così creato, a un nuovo progetto, e questo è il passaggio più critico.
Come accennato in altre parti, è opportuno, che in questa fase delicata, il client principale non abbia working units attive sul progetto in questione, perchè diventa, in caso di errore, estremamente probabile la perdita delle stesse o, meglio, l'elaborazione di queste risulterà inconsistente e perfettamente inutile (si vedrà meglio più avanti il motivo).
Dopo che verrà avviato il client secondario (meglio crearsi un file .bat o .sh), è meglio settare la scorta al valore minimo (tipo 0,01 giorni), per cercare di non scaricare nuove WU.
Si può procedere alla connessione al nuovo progetto, avendo anche cura di mettere il progetto nella condizione di bloccare immediatamente la richiesta di nuovo lavoro.
E' solo a questo punto che si può verificare se la procedura è andata a buon fine.
Se tutto è OK il progetto assegna al nuovo client multiplo un nuovo HostID (identificatore del computer) ed è fondamentale che questo codice HostID sia differente rispetto a quello del client principale.
Questo controllo può essere effettuato andando sul proprio account e chiedere la lista dei propri computer: se il nome del computer su cui si sta lavorando appare 2 o più volte (con codice hostID differente) allora l'operazione è andata a buon fine e si può andare avanti, altrimenti vuol dire che si è sbagliato qualche cosa, oppure il progetto non supporta la presenza di host multipli.
Si può anche andare a vedere nei rispettivi files client_state.xml l'assegnazione <hostid> nei due casi e verificare che i codici assegnati siano differenti.
Nel caso i codici assegnati siano uguali, l'eventuale scaricamento su un client, farà annullare le Wu scaricate dall'altro client.
Al momento attuale mi risulta non essere accettata la presenza di client multipli per i seguenti progetti:
DistributedDataMining, Rosetta@home, ralph@home, SAT@home, WUprop@Home (molto probabilmente questo limite è dovuto alla versione del server utilizzato, pertanto potrebbe anche succedere che in un domani questa limitazione non esista più)
mentre risulta essere funzionante (in quanto da me testato) sui seguenti progetti:
Atlas@home, BURP, CAS@home, Constellation, Enigma@Home, FiND@home, Gerasim@home, GPUGRID, Leiden Classical, Milkyway@Home, MindModeling@Beta, NFS@home, NumberFields@home, primaboinca, SAT@home, SETI@home, SETI@Home Beta Test, The Lattice Project, Universe@Home, Universe@Home Test, VirtualLHC@home, World Community Grid, yoyo@home.
Con quanto spiegato precedentemente chiunque è in grado di provare su altri progetto l'utilizzo di questa tecnica.
I vantaggi di questa tecnica nel caso di challenges:
in questo modo:
è possibile gestire ad esempio sul client principale un progetto di sola GPU e su quello secondario quello di CPU oggetto del challenge (o a parti invertite).
è possibile quindi gestire la rete per il client secondario in maniera diversa (cioè bloccarlo per non fare l'upload)
è possibile fare scorte su progetti di sola GPU che, nel caso di utilizzo della tecnica di VirtualBoxes, non funzionano