ARGOMENTO:

zioriga ha scritto:

Ma quello che più mi rode è che la perdita di WU già pronte per essere spedite è stata molto elevata

posso comprendere , si si ...comprendere

sabayonino ha scritto:

zioriga ha scritto:

Ma quello che più mi rode è che la perdita di WU già pronte per essere spedite è stata molto elevata

posso comprendere , si si ...comprendere

A chi lo dici!
GPUGRID? Cos'è?

GPU GRID non permette di fare scorte...finalmente un Ch vero e proprio!

Vale la pena mettere uno smartphone su gpugrid?

MA19-GORICIZZA-86MI ha scritto:

Vale la pena mettere uno smartphone su gpugrid?

Direi proprio di no...

in realtà di scorta ne aveva fatta tanta. Su un PC ne avevo già 13 pronte per essere spedite, e correttamente segnalate come ancora in corso, ma una manovra errata che ho fatto ieri sera me le ha annullate tutte

E questo significa anche che la scorta si può fare, ma bisogna lavorare con tanta calma e non uscire dalla strada seguita fino a quel momento

Gattorantolo ha scritto:

MA19-GORICIZZA-86MI ha scritto:

Vale la pena mettere uno smartphone su gpugrid?

Direi proprio di no...

Ok allora x sta volta passo

MA19-GORICIZZA-86MI ha scritto:

Gattorantolo ha scritto:

MA19-GORICIZZA-86MI ha scritto:

Vale la pena mettere uno smartphone su gpugrid?

Direi proprio di no...

Ok allora x sta volta passo

di app_cpu almeno fino a l'altro giorno non erano presenti.

comunque per quelle che ho elaborato in passato almeno la metà andavano in errore

ormai non mi sorprendo più

Rick! ha scritto:

sabayonino ha scritto:

zioriga ha scritto:

Ma quello che più mi rode è che la perdita di WU già pronte per essere spedite è stata molto elevata

posso comprendere , si si ...comprendere

A chi lo dici!
GPUGRID? Cos'è?

è quel progetto il quale dovrebbe pagare almeno 100 crediti per ogni WU andata in errore

sarei milionario a quest'ora

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

Suggerimento "Ricarica scorta in fase bunker pre-challenge"

Premetto che non ho ancora testato questa tecnica, ma sono abbastanza sicuro che funzioni.
Come bene sappiamo, la cosa importante del bunker è non reportare i risultati prima del tempo. Dato che la maggior parte dei progetti (a quanto ho letto in giro) usa lo stesso indirizzo IP per upload e report, non è possibile bloccare da router il solo report.

Allora possiamo fare così:
1) Settiamo il limite in upload al minimo possibile: 0,01kb/s, che nel software corrispondono a 10bytes/s.
2) Settiamo anche di trasferire al massimo 0,01 Mb (ovvero 10kb) ogni 1 (non so se si può mettere meno) giorni.

A questo punto avete 1000 secondi (ovvero circa 16 minuti) prima che vengano caricati 10kb di risultati. Se l'output delle vostre wu pesa più di 10kb avete un intero giorno per ricaricare la scorta, cosa vera per molti progetti, tra cui WCG.

si certo, dipende però dalle dimensioni di ogni singolo upload e di ogni singolo download.

ci sono dei progetti che hanno pochi caratteri per ogni WU/file, per cui non funziona. Se non ricordo male per esempio Collatz è di questi , ma sicuramente ce ne sono tanti altri

e poi in qualche caso il progetto vede troppe WU in upload e quindi "denuncia" la cosa (cioè te lo segnala) e non ti invia un bel niente

zioriga ha scritto:

si certo, dipende però dalle dimensioni di ogni singolo upload e di ogni singolo download.

ci sono dei progetti che hanno pochi caratteri per ogni WU/file, per cui non funziona. Se non ricordo male per esempio Collatz è di questi , ma sicuramente ce ne sono tanti altri

e poi in qualche caso il progetto vede troppe WU in upload e quindi "denuncia" la cosa (cioè te lo segnala) e non ti invia un bel niente

Hai ragione, mi ero dimenticato dell'errore "Not requesting tasks: too many uploads in progress". Sicuro al 100% che te lo segnala WCG. Al challenge di febbraio ho dovuto aspettare più di un'ora prima di poter cominciare a scaricare i nuovi task perché il mio bunker era completamente finito. Direi che il cerchio si restringe ancor di più. Se mi viene in mente qualcosa, faccio sapere.

guarda che gli unici modi per aumentare il bunker in corso d'opera sono le VM o i client multipli

zioriga ha scritto:

guarda che gli unici modi per aumentare il bunker in corso d'opera sono le VM o i client multipli

Se per esempio fai bunker di wu da 6h che il cui output pesa +100kb (le MCM che sto computato su WCG, ma anche le wu di Rosetta per citarne di simili), questo metodo di "ricarica" potrebbe funzionare tranquillamente. Il tutto dipende dalla durata della fase di bunker e dal limite di upload in corso. Un tentativo in tal senso non nuoce se si può evitare di il rischio di errori con i client multipli oppure occorre crearsi una vm (che magari si pensava non servisse) durante il bunker e quindi consumare preziose risorse. Penso che la situazione ideale sia di avere almeno un paio di vm sempre pronte per l'uso.

a seguito di prove effettuate su client installato in RAM, di cui in apposito thread, ho scoperto che i progetti che non permettevano l'utilizzo di client multiplo, in realtà, se si "installano" su un client RAM, tutto funziona correttamente.

Per adesso ho testato sui progetti Rosetta@home e WUProp@home, e sembra funzionare (gli hostID sono generati correttamente, differenti rispetto a quelli generati da client su HD).

Aspetto conferme anche da chi vuole provare.


PS. probabilmente bisognerebbe andare a sfrucugliare nei sorgenti di BOINC per essere più sicuri sul processo di assegnazione del codice hostID

zioriga ha scritto:

a seguito di prove effettuate su client installato in RAM, di cui in apposito thread, ho scoperto che i progetti che non permettevano l'utilizzo di client multiplo, in realtà, se si "installano" su un client RAM, tutto funziona correttamente.

Per adesso ho testato sui progetti Rosetta@home e WUProp@home, e sembra funzionare (gli hostID sono generati correttamente, differenti rispetto a quelli generati da client su HD).

Aspetto conferme anche da chi vuole provare.

Proverò sicuramente su CMS dev, potrebbe essere una comoda maniera per raddoppiare il RAC. Questo però lo farò quando sarà terminato il challenge Montalcini.

Visto che in altri threads divampano polemiche, voglio aggiungere qua un consiglio per gli amanti dei bunkers.

Per tutto questo thread si è parlato di creare il bunker per l'inizio del challenge: cioè di iniziare a fare scorta tot giorni prima dell'inizio stesso del challenge.
E fin qui non fa una piega.

Ciò che segue è vero solo per i challenges sui progetti a quorum 2 (che sono la larga maggioranza)

In realtà il challenge è "composto" di due date: esiste infatti la data di fine challenge.

Questo vuol dire che si devono fare due bunker: uno per l'inizio e l'altro per la fine.

Questo però comporta saper "giocare" con i clients multipli (si guardi il thread apposito)
Può capitare anche che per garantire la piena occupazione dei propri pc si debbano creare molti clients multipli (dipende anche da quante wu il progetto riesce a fornire)