ARGOMENTO:

Challenge su Boincstats indetto da BOINC.Italy per la recente scoperta Nasa di ben 7 esopianeti nel sistema TRAPPIST-1, una stella nana ultrafredda a soli 39,5 anni luce da noi I pianeti sono di natura rocciosa e 3 di essi si trovano in fascia "abitabile", con probabile presenza di acqua allo stato liquido
Articolo su Wikipedia:



Inizio: 08-03-2017 08:00 ora italiana
Fine: 15-03-2017 08:00 ora italiana

Progetto: SETI@home

Link al challenge su Boincstats:

Classifica interna utenti BOINC.Italy by Nubman:

almeno un post di presentazione su BS ...

Ispirazione zero

Direi che anche una locandina in home sarebbe gradita

Propongo questa img che mi sembra carina: www.media.inaf.it/wp...ent/uploads/2017/02/PIA21421-272x340.jpg

Inoltre, indico già che ci sono delle pratiche legalissime per massimizzare i crediti su SETI@Home.

1) GUPPI Rescheduler: setiathome.berkeley.edu/forum_thread.php?id=79954
2) Applicazioni ottimizzate: lunatics.kwsn.info/index.php?action=downloads

Si ricorda ancora che il progetto ha una manutenzione settimanale (martedì), per cui conviene avere code della durata di almeno 2gg (non quelli di BOINC, dovete calcolarli in base alla velocità dei vostri host) per stare sicuri.

Direi ottima proposta quella dell'immagine avanzata da Nubman, bisognerebbe però completarla con i dati del challenge.

Una volta c'era Mantis che lo faceva, ora chi si fa avanti ??


Ottimo anche ricordare le app "ottimizzanti"

Ahiahi, vedo che questo progetto limita il numero di tasks in progress a 100 qualsiasi sia la cpu/gpu. Senza ulteriori smanettamenti si hanno code abbastanza corte.

è da anni che il limite è a 100 Wu di CPU + 100 Wu di GPU

bisogna lavorare pesantemente di client multipli.
Io non ho ancora provato l'app GUPPI, o forse l'avevo provata tanto tempo fa.
Ma per adesso lavoro con client multipli

Speriamo di riuscire, più o meno per tempo, a mandare una mass mail (a quelli che si riuscirà ad inviare) e/o a utiklizzare i canali alternativi.

Non ho mai fatto bunker su SETI@Home in vita mia. :bua:

Da venerdì forse avrò tempo per organizzare i client multipli, però che fatica!


P.S. sui client CPU-only il GUPPI Rescheduler non serve a niente e la pratica VLARkill, ossia abortire tutte le wu inefficienti (e da destinare alle GPU di altri), è ovviamente scoraggiata:

P.S. sui client CPU-only il GUPPI Rescheduler non serve a niente

Cosa vuoi dire ??
Forse se nel client hai sia CPU sia GPU allora funziona ??

zioriga ha scritto:

P.S. sui client CPU-only il GUPPI Rescheduler non serve a niente

Cosa vuoi dire ??
Forse se nel client hai sia CPU sia GPU allora funziona ??

Quel rescheduler, a BOINC spento, individua le wu efficienti su GPU e/o quelle efficienti su CPU. Tutte le wu GUPPI o in generale tutte quelle che non sono VLAR vanno alla CPU, le restanti alla GPU. Quindi, esso opera dei cambiamenti in alcuni file per riassegnare la piattaforma/applicazione sulla quale devono essere elaborati. Si può fare anche a mano, io l'ho fatto una volta su LHC, ma non bisogna sbagliare nulla.

Se fai girare il rescheduler in mancanza di GPU, mettiamo pure che funzioni e ci siano dei task (per esempio i VLAR) riconosciuti inefficienti su CPU... cosa te ne fai? A chi li riassegni? Infatti, alcuni utenti hanno preso ad abortire questi lavori, ma la cosa degenererebbe se lo facessero tutti e quindi ha senso sconsigliarlo fortemente.

Piccola rettifica o meglio il contrario di quello che avevo detto: è la GPU a essere inefficiente sui task nel cui nome compare VLAR. In effetti, se non ho capito male, il GUPPI Rescheduler assegna alla GPU soltanto quei task con un nome simile a "02au10ab.18564.8376.13.40.180_1" mentre assegna alla CPU i task con un nome tipo "09jn10aa.17962.14382.13.40.160.vlar_0". A elaborare questi VLAR la GPU raddoppia (se non di più) i tempi di elaborazione mentre la CPU peggiora del 30% rispetto alla norma.

Aggiungo che in termini di RAC non è detto che si abbia un grosso miglioramento. In più le prestazioni di CPU e GPU si mischiano perché il server non è in grado di capire che un lavoro mandato alla GPU è stato svolto dalla CPU e viceversa, ma i migliori tempi di esecuzione dovrebbero in generale indurre il sistema dei crediti a normalizzare i crediti garantiti in positivo.

La ripianificazione (rescheduling) giova in primis al progetto stesso in quanto il server spedisce il lavoro randomly, dunque senza pensare a quale piattaforma sia più efficiente in uno specifico lavoro.

Problema: la classifica interna non va.

Praticamente non è il codice a generare il malfunzionamento, ma qualche limitazione lato server su cui non posso agire. L'esecuzione localmente sul mio pc funge. L'esecuzione sul server con team più piccoli funge. Non posso fare nulla se il nostro team è troppo pesante da scaricare. Inoltre, lo script va pericolosamente in loop (il server lo fa girare all'infinito, mah!) rischiando di causare un ban del dominio.

Suggerimenti?

Edit: ho creato uno script di prova per scaricare soltanto il file xml da SETI@Home e funge. Dunque, non è una limitazione in download. La cosa strana è loop di cui sopra perché non è dovuto al mio codice. Forse il problema è la dimensione di alcune variabili che fa "crashare" l'esecuzione lato server, altrimenti non saprei.

Edit2: in realtà non funziona neanche localmente. La riscrittura dei valori di classifica si blocca ben prima del 5000esimo utente (e gli utenti SETI sono 5610!). Non mi è mai capitato questo bug prima d'ora e la risoluzione non mi sembra immediata. Anche liberando lo spazio in runtime non si ottengono miglioramenti. L'esecuzione si arresta di colpo a volte prima a volte dopo, ma si arresta.

@Nub , ti piace giocare con il fuoco

Come non detto, ho attivato i log in PHP. E' soltanto il limite dei 30 secondi di esecuzione il problema. A questo punto "l'unico problema" rimasto è snellire la scrittura dei valori.

EDIT: Ho riesumato il codice della classifica del Pentathlon. Mi ero dimenticato che quello è già ottimizzato nella scrittura. Ci mette 24 secondi, quindi sta nei tempi.

Come già detto in chat, stamattina ci sono stati dei problemi nell'effettuare la prima rilevazione della sfida. La limitazione (lato server) del tempo di esecuzione dello script a 30 secondi aggiunta a un tempo di download del file degli utenti del team più lungo del normale ha fatto sì che alle 08:00 la rilevazione fallisse. Ne ho tentata una manuale poco dopo alle 08:10, ma pure quella è fallita. Finalmente intorno alle 08:20 la prima rilevazione è stata effettuata con successo, ma qualcuno aveva già cominciato ad uppare il bunker.

Adesso alle ore 19:00 (più o meno ) ho fatto un confronto dalla classifica di BS e la mia. Devo dire che, a parte zioriga che ha sicuramente cominciato ad uppare il bunker da subito, le altre fluttuazioni dei punteggi sono indistinguibili da quelle dovute alla mancanza di sincronizzazione tra gli aggiornamenti delle due classifiche. Su alcuni utenti infatti è addirittura risultato che nella classifica interna da me realizzata il punteggio sia più alto mentre un ritardo nella prima rilevazione comporterebbe sicuramente un punteggio più basso se ci fosse una grossa differenza.

Dunque, direi che posso correggere il punteggio di zioriga aggiungendogli 75000 crediti forfettari cosicché si continui a usare la classifica interna già linkata. Per la classifica finale invece sarebbe meglio prendere i valori corretti da BOINCstats.

ok, mi sembra che adesso i valori nelle due classifiche coincidano

arrivo ora a uppare quel poco che ho...

ragazzi 1 o 2 progetti sono già stati inviati da qualche ora ma ancora non sono nella nostra classifica
boincrankings.eu5.org/trap/classifica.php?id=1
sbaglio qualcosa?