ARGOMENTO:

Visto l’aumento dell’interesse di molti alla partecipazione ai challenge, mi sembra opportuno incominciare a spendere alcune parole in merito alla preparazione ottimale per queste sfide.
La prima cosa importantissima è la creazione della riserva iniziale per i challenges, su cui mi voglio ora dilungare, riassumendo sia varie proposte apparse sul sito, sia anche mie esperienze.
Teniamo presente però che tutto quanto segue è da considerarsi come una linea guida generale e che, a seconda delle caratteristiche dei progetti coinvolti, ci potranno essere delle modifiche.

Sicuramente alcune parti potranno essere un pò ostiche e magari comprensibili solo agli addetti ai lavori, e magari possono contenere qualche inesattezza, ma confido anche sulla collaborazione di tutti voi per migliorare quanto scritto.

Data inizio challenge e deadline del progetto.
Le prime due informazioni importanti sono proprio la data di inizio challenge (attenzione alla data UTC) e la deadline del progetto (intendendo la deadline come l’intervallo di tempo entro cui deve/dovrebbe essere elaborata la WU.
La data inizio progetto è nota, così pure sono facilmente reperibili i dati di deadline anche in funzione del particolare sottoprogetto su cui si bassa il challenge (vds wuprop.boinc-af.org/results/delai.py).
Andando quindi a ritroso si riesce a sapere quando iniziare a scaricare le WU per il challenge.
Il massimo sfruttamento di questo periodo sta nell’iniziare a scaricare nell’istante (data inizio challenge meno deadline) il massimo numero possibile di WU, elaborarle durante il periodo del challenge e riconsegnarle tutte appena dopo la data di inizio.

Quante WU si possono elaborare nel periodo pre-challenge ??
Questo valore ovviamente varia da progetto a progetto, da PC a PC, da quante ore al giorno si lascia acceso il PC, da quale % di elaborazione è assegnata a BOINC.
Si può provare però a fare qualche prima considerazioni e i ragionamenti che seguono fanno riferimento a elaborazione continua H24 e al 100% di utilizzo..
Intanto è nota la potenzialità di calcolo in ore pari a n. giorni di deadline per 24 e per il numero di cores presenti nel PC . L’incognita mancante è il valore medio in ore per il completamento delle WU: questo è un dato ovviamente tipico della capacità di calcolo del PC e solo dalle prove effettuate da ciascuno si potrà avere un valore medio di riferimento.

Pertanto il numero teorico sarà

n.gg deadline x 24 x n.cores

---

Durata media (in ore) WU

Ribadisco ancora che è importante che le WU scaricate ed elaborate dovranno, al fine del challenge, essere consegnate e validate dopo l’inizio del challenge.

Come iniziare a scaricare all’inizio del pre-challenge ?

Nella maggioranza dei casi i challenges iniziano alle ore 00.00 UTC che sono o le 01:00 nel caso di ora solare o le 02:00 nel caso dell’ora legale.
Vista l’ora, i casi sono 2:
- o si rimane svegli sino a quell’ora e quindi si mette il progetto in grado di ricevere WU e poi si clicca furiosamente sul tasto di aggiorna per poter ricevere WUs
- o si imposta, con le ore opportune, tramite scheduler del sistema operativo i comandi di riattivazione e di aggiornamento del progetto, con il programma boinccmd.exe che è nella directory dove è installato il programma Boincmanager.
- I comandi da inviare sono
- boinccmd –project URLproject allowmorework
- boinccmd –project URLproject update

dove URLproject va sostituito con l’indirizzo Url del progetto.
Per una trattazione completa del comando boinccmd vedere boinc.berkeley.edu/wiki/Boinccmd_tool

In teoria si può anche anticipare rispetto all’ora ufficiale, in funzione della durata di ogni singola WU, ma non è detto che si possa fare con tutti i progetti e soprattutto l’anticipo dovrà essere inferiore alla durata di una singola WU.




Come riuscire a ricevere il numero teorico di WU all’inizio del pre-challenge?
Prima cosa da fare è mettere il massimo possibile alla scorta (10gg+10gg) sia nelle preferenze del BOINC Manager nella sottopagina dell’utilizzo della rete, sia controllarlo anche nella pagina del progetto che si raggiunge dalla pagina dell’account e poi delle preferenze.
Nella maggioranza dei casi il numero teorico di cui sopra è superiore al quantitativo che il progetto assegna all’utente come quota giornaliera (dopo ripetute richieste di aggiornamento, si arriva a un punto in cui il progetto non trasmette più WU e segnala “reached daily quota”).
Su alcuni progetti esiste la possibilità di far credere al progetto di aver un PC + potente in modo da riuscire a ricevere all’inizio un numero di WU molto alto.
Si basa sulla presenza del file cc_config.xml (vds boinc.berkeley.edu/wiki/Cc_config.xml)
Una configurazione minimale potrebbe essere:
<cc_config>
<options>
<ncpus>N</ncpus>
<fetch_on_update>1</fetch_on_update>
</options>
</cc_config>

Dove con N si deve sostituire un valore genericamente multiplo del numero di cores presenti sul PC. Su alcuni progetti sono anche riuscito a impostare un valore pari a 100 e come risultato è stato l’inondazione di WU !!.

Prima di far questo però si deve entrare sul progetto, nel proprio account e nelle preferenze di elaborazione andare a settare il corretto valore del parametro indicato come “Su sistemi multiprocessore, usa al massimo xx processori”.

Si consiglia di fare questa operazione dopo aver settato la % di elaborazione a un valore molto basso.
e inoltre è meglio non esagerare con il mettere valori molto alti di ncpus

Successivamente si fa leggere a Boinc il config files e poi si chiede l’aggiornamento del progetto.
Scaricato un numero congruo di WU si deve correggere il valore N in -1 e far rileggere il file di configurazione in modo da tornare alle condizioni standard e riportare la % a 100%.

Esiste ormai un valido gestore del file cc_config.xml.
lo trovate a questo link boinc.berkeley.edu/a....com%2Fp%2Fboinc-client-configuration%2F
l'applicazione rileva automaticamente la posizione dovbe deve stare il fil cc_config e nel tab con la dizione Option3 si può modificare a piacere il numero di ncpus

Come riuscire a elaborare le WU senza fare l’upload al progetto ?

Esistono alcune tecniche che presentano però vantaggi e svantaggi:

. programma BoincTasks
Su www.boincitaly.org/f...sks-un-alternativa-al-boinc-manager.html trovate una buona spiegazione sul funzionamento di questo programma.

Purtroppo però è un programma non sicuro al 100 %, nel senso che anche impostata una regola di bloccare la WU al raggiungimento di una determinata percentuale, non è detto che la WU sia poi effettivamente fermata a quella percentuale o poco oltre.
Ci sono stati casi dove il programma non è riuscito a fermare tutte le WU, alcune sono andate al 100 % .
E’ stata anche lanciata l’ipotesi di lavoro di creare 2 regole di blocco a percentuali differenti (tipo l’80% e il 90%), sperando che almeno una delle due sicuramente funzioni.
Su questo per ora io non ho niente da dire non avendolo provato.

. bloccare l’attività di rete tramite boincmanager
Questo sistema ovviamente garantisce che le WU elaborate durante il pre-challenge non siano uploadate, ma ha l’ovvio svantaggio che non permette di elaborare eventuali altri progetti che l’utente abbia voglia di elaborare.

. bloccare l’IP del progetto
O tramite il firewall del sistema operativo e tramite il firewall del router, il blocco del traffico verso l’IP del progetto, risulta una tecnica migliore rispetto alla precedente nel caso si voglia elaborare contemporaneamente altri progetti.
Nel caso di Windows il firewall lo si raggiunge dal pannello di controllo: si deve creare una regola
Per conoscere l'indirizzo IP del progetto c'è il seguente sito ipaddress.com/search/

. vedere anche i posts successivi per l'interessante tecnologia di manipolazione del file hosts

Cosa fare se tutte le WU sono terminate/bloccate ?
In questo caso dipende da ciò che è stato adottato al punto precedente.

Nel caso di blocco dell’attività di rete tramite boincmanager esiste la possibilità di creare/utilizzare un PC virtuale, per esempio di tipo Linux, con il quale scaricare ed elaborare altre WU. I programmi di virtualizzazione più usati sono VirtualBox e VMPlayer.
Da prove fatte mi risulta che il sistema Linux più “user frienly” sia la versione Mint.

Nel caso del blocco IP sembrerebbe non sia possibile fare più niente (se si riapre l’indirizzo IP, automaticamente tutto ciò che è terminato viene uploadato).
Esiste però qualche caso di progetto che ha differenti indirizzi IP (uno per fare il download e l’upload e l’altro per l’aggiornamento/validazione).
Su questi casi si dovrà fare riferimento ai thread di discussione sui challenges.

Nel caso di utilizzo di BoincTasks si può utilizzare una macchina virtuale come sopra specificato oppure si è obbligati a:
- fermare il funzionamento di BoincTasks
- sbloccare tutte le WU,
- eseguire “freneticamente” richieste di aggiornamento e, se finalmente sono state scaricate nuove Wu,
- procedere a ribloccare tutte le Wu
- rifar partire il programma BoincTasks

si può anche utilizzare la tecnica della modifica del parametro ncpus di cui precedentemente, ma è da utilizzare con molta delicatezza perché l’avvio contemporaneo di un numero enorme di WU può comportare il blocco del PC.

Cosa fare al momento dell’inizio del challenge ?

Se abbiamo iniziato a scaricare WU all’istante ottimale, siamo obbligati a iniziare a fare l’upload 1-2 minuti dopo l’inizio del challenge (tipicamente di notte, esattamente come abbiamo fatto nello scarico WU nel pre-challenge).

Nel caso di utilizzo di BoincTasks, si dovrà aver precedentemente liberato tutte le WU, bloccata la rete (per impedire l’upload) per permettere il completamento di tutte le WU e quindi riaprire la rete con il comando (da programmare con lo scheduler)

boinccmd –set_network_mode always

Questo caso comprende ovviamente anche il caso in cui si sia scelto di non utilizzare BoincTasks ma utilizzare dall’inizio il blocco della rete

Nel caso del blocco IP, l’unico modo che io sappia è quello di stare sveglio ed agire manualmente con lo sblocco dell’indirizzo

Un'altra tecnica per andare a bloccare l'upload e il download delle WU può essere quella di intervenire direttamente sul file HOSTS.

Il file HOSTS viene interrogato per primo dal nostro computer per la risoluzione dei nomi DNS in indirizzi IP.
Modificando il file HOSTS posso far puntare il mio PC verso un indirizzo a mio piacimento per un determinato nome DNS (es. www.boincitaly.org). Basta indicare in una nuova riga l'indirizzo IP (seguito da uno spazio o da una tabulazione) e il nome del dominio da bloccare.
Nel mio caso non voglio che il client BOINC comunichi con lo Scheduler del progetto vero, ma che cerchi il server nel mio PC, ottenendo quindi un errore di comunicazione. Per fare ciò indico l'indirizzo 127.0.0.1 che sta ad indicare l'indirizzo di Loopback della mia scheda di rete, quindi il mio PC locale.

Ma.... Prima di tutto devo conoscere l'indirizzo dello Scheduler del progetto che voglio bloccare.

La URL dello scheduler da bloccare va ricercata all'interno del file client_state.xml che solitamente si trova all'interno della directory C: \ ProgramData \ BOINC \
Con Notepad o simili cerco il nome del progetto dentro il file client_state.xml. Una volta trovato il progetto cerco all'interno della sua sezione cerco il valore del parametro <scheduler_url>. Lo copio e lo incollo

IMPORTANTE: va preso in considerazione solo la root del dominio senza http(s):// e senza le successive virtualdir /

ESEMPI VALIDI:
http ://www.boincitaly.org/bimbo/main.html ===> www.boincitaly.org
http :// boincitaly.org/upload/default.wsdl ===> boincitaly.org
https ://ww2. boincitaly.org/index.html ===> ww2.boincitaly.org

Una volta estrapolata la root del dominio che voglio bloccare, apro il file HOSTS

Il file HOSTS si trova solitamente in C: \ Windows \ System32 \ Drivers \ Etc \ , lo apro con un editor di testo e aggiungo una nuova riga:

127.0.0.1 www.boincitaly.org

Salvo il file HOSTS

E' buona abitudine pulire la cache del sistema operativo in quanto vegono tenuti in cache per un brevissimo periodo gli ultimi server contattati, e potrebbe capitare che nonostante la nostra modifica sul file HOSTS, la cache del DNS possa continuare a far risolvere l'indirizzo corretto del server, e non il 127.0.0.1 che abbiamo indicato nel file HOSTS.
Per evitare ciò apro un Prompt dei Comandi (CMD.EXE) e digito: IPCONFIG /FLUSHDNS

A questo punto i programmi che girano nel mio PC quando vanno a fare una richiesta in rete per l'indirizzo www.boincitaly.org non faranno riferimento al server reale ma al mio PC, e non funzioneranno...

Se dal prompt dei comandi digito:

PING www.boincitaly.org

vedrò che la risposta del server sarà da 127.0.0.1 (il mio PC).


All'interno del file HOSTS ogni singola riga può essere commentata con il metacarattere # e questo può tornare utile per mettere ordine all'interno del file e anche per mettere/togliere il blocco di un progetto in maniera veloce.
Per tenere un po' d'ordine e per renderlo meglio leggibile, uso il tasto TAB per creare lo spazio tra 127.0.0.1 e la URL da bloccare (anche se qui nel post non si vede...)

Esempio

########## BOINC
# GPU Grid
#127.0.0.1 www.ps3grid.net

# Rosetta
#127.0.0.1 srv4.bakerlab.org

# Collatz Conjecture
127.0.0.1 boinc.thesonntags.coma

Fine Esempio

Nell'esempio riportato risulta bloccato solo il progetto Collatz Conjecture, mentre GPU Grid e Rosetta sono commentati dal carattere # all'inizio della riga





Hello IT?
....
Have you tried turn it on and off again?

per i pinguini tale file è posizionato in /etc/hosts
Le modalità di utilizzo sono pressochè identiche

esempio di file hostsricordo che il cancelletto "#" , non viene considerato dall'interprete utilizzato (dipende dal linguaggio di scripting , bash in questo caso) per cui tutto quello che segue il "#" non è considerato o comunque viene utilizzato per commentare parti dello script.

Molto interessanti queste aggiunte, che possono essere considerate come una valida alternativa a:

. blocco totale dell'indirizzo IP del progetto a livello di router (che ha lo svantaggio che blocca totalmente la comunicazione con quel progetto)

. blocco totale della connessione in rete del programma BOINC (con lo svantaggio che non permette di interfacciarsi con altri progetti)


Questa tecnica risulta quindi particolarmente interessante nel caso si debba gestire più di un PC e ciascuno su progetti diversi. Questo è proprio il caso della partecipazione alla sfida BOINC Pentathlon.

Come ultima aggiunta, a livello teorico, la soluzione migliore dovrebbe essere il poter bloccare la comunicazione (l'upload) con il progetto a livello di solo programma BOINC, a meno che non si possa agire a livello di firewall personalizzato (forse bisognerà fare delle prove)



In aggiunta, segnalo questo sito ipaddress.com/search/. Sottoponendogli l'URL del progetto, restituisce l'indirizzo IP

zioriga ha scritto:

In aggiunta, segnalo questo sito ipaddress.com/search/. Sottoponendogli l'URL del progetto, restituisce l'indirizzo IP

Attenzione che in alcuni casi (almeno in passato e non ricordo per quali progetti) , l'url dell'attack non sempre corrispondeva all'URL dell'upload (nemmeno il master)
inoltre nel file hosts non è obbligatorio indicare l'indirizzo IP ,si può indicare anche l'URL completo (a patto che sia quello effettivo dove viene fatto l'upload e/o report del progetto)

si dovrebbe stilare un elenco ed aggiungere questo url/ip alla pagina dl progetto qui su BI (sperando che il progetto stesso non cambi l'url troppo spesso)

docs.google.com/spre...XsN1WxEKPeidWGRTvfl-i2-W8SgssWFJWaealLo/ :D

danieleg ha scritto:

https://docs.google./spreadsheets/d/15com8ikXsN1WxEKPeidWGRTvfl-i2-W8SgssWFJWaealLo/ :D

già qualcosa ... e gli altri 100 e passa progetti ?

Lo aggiorno solo quando c'è un challenge

danieleg ha scritto:

Lo aggiorno solo quando c'è un challenge

boincstats.com/en/stats/challenge/team/overview ecco ... accomodati


scherzi a parte , intendevo trovare la voce (aka file) all'interno della cartella dove viene indicato l'indirizzo di upload/report ... se non sbaglio è indicato da qualche parte senza star lì a fare "sniffing" di rete

sabayonino ha scritto:

danieleg ha scritto:

Lo aggiorno solo quando c'è un challenge

boincstats.com/en/stats/challenge/team/overview ecco ... accomodati


scherzi a parte , intendevo trovare la voce (aka file) all'interno della cartella dove viene indicato l'indirizzo di upload/report ... se non sbaglio è indicato da qualche parte senza star lì a fare "sniffing" di rete

$PathBoincData/master_[URL_prj].xml

Ad esempio per win: c:\pogram data\boinc\master_ralph.bakerlab.org.xml

per *nix: /var/lib/boinc/master_ralph.bakerlab.org.xml


L'avevo trovato e scritto in qualche thread challenge-related (mi sembra) nelle scorse settimane, se qualcuno è bravo a trovarlo c'è tutto...

sabayonino ha scritto:

danieleg ha scritto:

Lo aggiorno solo quando c'è un challenge

boincstats.com/en/stats/challenge/team/overview ecco ... accomodati

Ovviamente intendevo solo quelli a cui partecipiamo , un po' alla volta si completerà....

scherzi a parte , intendevo trovare la voce (aka file) all'interno della cartella dove viene indicato l'indirizzo di upload/report ... se non sbaglio è indicato da qualche parte senza star lì a fare "sniffing" di rete

Questo è il messaggio di Rick: link
Il problema è che nella maggior parte dei casi viene riportata l'url e quindi almeno un ping devi farlo.

ecco occorre cercare il tag "scheduler"
e conferma quanto descritto sopra




preparo la lista ? (almeno per i progetti ai quali sono iscritto )

ecco alcuni
Da notare che quasi tutti seguono l'URL principale

per Enigma... è un enigma non mi ha restituito nulla

Aggiunti.

danieleg ha scritto:

Aggiunti.

aggiungerei anche la colonna con l'URL ... non si sa mai

.. e se vuoi dare un tocco di sobrietà al FE ... i nomi progetto li ho scritti un pò di fretta ...

vedo con piacere che vi siete scatenati su questo fronte

zioriga ha scritto:

vedo con piacere che vi siete scatenati su questo fronte

ci sono residui di "adrenalina" del penta ...

Client BOINC multipli sullo stesso pc Linux


Con questa tecnica si possono avviare più client BOINC su uno stesso pc Linux, con la possibilità di esecuzione simultanea dei vari client. E' molto utile nei casi in cui il progetto distribuisce un numero molto limitato di wu, anche se si fa uso di trucchi come quello di simulare più core con l'opzione --ncpus.

Per pc Windows esiste questa guida di @@$tars_Finder@@. Io l'ho provata con scarso successo e non mi sento di consigliare di fare questa cosa su Windows

L'alternativa a questa procedura è quella di creare delle virtual machines in cui avviare altri client, ma questa tecnica è decisamente conveniente. Bisogna però verificare che il progetto tolleri questa procedura perché alcuni vedono i vari client come una unica macchina ed annullano le wu inviate quando si avvia un nuovo client.
Questi sono i progetti che ho testato:

SI
Milkyway
SETI
pogs

NO
rosetta
wuprop
world community grid

Le istruzioni sono per utenti Ubuntu e simili ma si possono adattare alle altre distribuzioni.
Useremo il BOINC dei repository di ubuntu, quindi se non lo abbiamo già bisogna installarlo:

A questo punto abbiamo il client principale già attivo. Creiamo la directory per il secondo. Le metto sulla scrivania così sono raggiungibili facilmente, ma va bene qualsiasi posizione nella propria home

Creiamo il file della password vuoto per garantire la connessione del manager. Chi preferisce avere la password può editarlo e mettere quella che preferisce:

A questo punto se vogliamo possiamo già crearci il file di configurazione cc_config.xml, oppure copiarlo dalla directory standard così:

Adesso possiamo avviare il nuovo client. E' importante specificare una porta di comunicazione diversa da quella che usa il primo client (31416) per tenerli ben distinti:

Apriamo il boinc manager e ci connettiamo al nuovo client con Avanzate>Seleziona un computer..., inserendo 127.0.0.1:31417 ed eventualmente la password. Usare localhost come indirizzo non sembra funzionare

E' importante usare una porta diversa per ogni client. Vanno bene quelle dalla 31417 in su.
Attenzione a modificare i comandi sostituendo la directory e la porta da usare ogni volta che si avvia un nuovo client. Significa che per il terzo client useremo la directory boinc3 e la porta 31418

Una volta finito il lavoro con il client si può chiudere dando ctrl-C sul terminale. Per riavviarlo rieseguire l'ultimo comando

A seguito di "prove" con gli utlimi due challenges (Milkyway e SETI) e di aver perso una marea di WU, causa di un uso non del tutto corretto di questa tecnica, qualche barlume di chiarezza mi si sta aprendo davanti agli occhi.

Direi assolutamente importante verificare che la creazione del client ulteriore sia andato a buon fine.

Per far questo, appena creato il nuovo client, verificare subito che nell'elenco dei computers sul progetto appaia questo nuovo client con un nuovo codice numerico identificativo.
In altre parole nell'elenco dei computers deve apparire un nuovo PC con lo stesso nome di quello "principale! (quello identificabile con l'utente "localhost") ma con un codice identificativo nuovo. (P.S. Questo codice dovrà essere uguale a quello che si trova nel file client_state.xml sotto il blocco di info relative al progetto)

Nel caso positivo si può procedere oltre allo scarico di nuove WU, altrimenti è meglio annullare il progetto sul nuovo client, e ripetere l'operazione, finchè non risulterà creato sul sito il nuovo client.

Come modalità alternativa, e che mi pare stia funzionando meglio è quella di inserice nel cc_config.xml la riga

<allow_multiple_clients>1</allow_multiple_clients>

e quindi, per passare dal client principale a quello nuovo, da menù, passare da Avanzate ->Avvio di un altro BOINC Manager

Avevo scritto:

Direi assolutamente importante verificare che la creazione del client ulteriore sia andato a buon fine.

Per far questo, appena creato il nuovo client, verificare subito che nell'elenco dei computers sul progetto appaia questo nuovo client con un nuovo codice numerico identificativo.
In altre parole nell'elenco dei computers deve apparire un nuovo PC con lo stesso nome di quello "principale! (quello identificabile con l'utente "localhost") ma con un codice identificativo nuovo. (P.S. Questo codice dovrà essere uguale a quello che si trova nel file client_state.xml sotto il blocco di info relative al progetto)

con il tentativo di creazione di scorta con il ch su GPUGrid, la "certezza" che avevo acquisito sull'argomento, è andata a farsi benedire !!!!!

il comportamento su quest'ultimo progetto sembra essere totalmente in contrapposizione con i precedenti: nel senso che i pc che avevano creato diversi ID ora hanno avuto un ID unico, mentre quelli che avevano creato un ID unico, ora ne hanno creati 2.

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

ma non mi scoraggio, devo assolutamente trovare la quadra sull'argomento.

se qualcun altro vuol farsi avanti con le sue esperienze, è il benvenuto