ARGOMENTO:

** Discussione sull'articolo: LHC@Home spreca il tempo degli utenti? **

Ultimamente avevo notato molte WU annullate dal progetto... forse questa è la spiegazione che cercavo.

Riguardo alle strategie: anche solo fissare IR=MinQ per la prima sfornata ed eventualmente IR>MinQ per la seconda (qualora MinQ non dovesse essere raggiunto) è una strategia migliore di quella scelta.
E anche se non si potesse fare... e chi se ne frega ! Strategie che pensano solo al progetto e non al nostro criceto mi sono sempre andate di traverso (anche la deadline breve a volte è una bella rogna).

Cosa facciamo noi? Io aspetto la risposta dei rappresentanti del progetto e poi valuto se è il caso di continuare

Direi aspettare la replica dell'altra campana, cioe' i responsabili del progetto.

Un sacco di user al primo sentore di sprechi giustamente danno di matto, e incitano al boicattaggio, tuttavia direi che questo non e' uno di quei casi estremi tipo il RieselSieve che visto come e' stato abbandonato dal gestore sembrava fatto "tanto per fare", oppure del milkway che di fatto spreca il 99,95% del tempo macchina dedicato.
Qui dobbiamo anche tenere conto che eventuali risultati errati possono impattare "fisicamente" sull'esperimento, con sprechi di energia probabilmente molto piu' grandi di quelli chiamati in gioco dal loro sever BOINC.

Insomma se un progetto non convince non si elabora piu', punto. Come mi e' capitato per il Rosetta che anche a un tentativo recente mi dava un sacco di WU errorate. Ma non per questo sono andato a denigrare il progetto pubblicamente, perche' la % di computation error reale non la posso calcolare io come utente ma e' visibile solo ai responsabili del proegtto.

Sono deluso, avrei accettato una politica del tipo:

100% dei crediti al primo che finisce una WU

90% al secondo,

80% al terzo e via di 10% in meno ad ogni volontario.

Con lo 0% non è calcolo distribuito, è una presa per il C...

Finchè non viene chiarita questa cosa, LHC non vedrà i miei

...

Anche io come baxnimis vedevo anomalie nella gestione nelle Wu. Comunque siccome sono previdente e ho un quad, ho destinato un solo core a lhc.. quindi alla fine il \"danno\" è contenuto.

Peccato, lhc è proprio un progetto valido.

astroale ha scritto:

Direi aspettare la replica dell'altra campana, cioe' i responsabili del progetto.

quoto astroale

campos ha scritto:

Sono deluso, avrei accettato una politica del tipo:
100% dei crediti al primo che finisce una WU
90% al secondo,
80% al terzo e via di 10% in meno ad ogni volontario.

Non sono d'accordo chi arriva a calcolare dopo il primo ha fatto lo stesso lavoro e quindi ha diritto allo stesso riconoscimento, e infatti e' cosi' che funziona.

Con lo 0% non è calcolo distribuito, è una presa per il C...

Occhio, non c'e' assolutamente scritto questo nell'articolo.
Il tizio si lamenta solo per il fatto che dopo il terzo risultato identico sulla stessa WU il server permetta ai client che hanno in carico la quarta e la quinta istanza della WU di continuare il calcolo se questo e' gia' in corso. E non che non vengono assegnati crediti.

Francamente la valutazione sull'IR e' e deve essere nella assoluta disponibilita' di ogni gestore di server BOINC. Eventualmente il gestore del server potrebbe essere piu' trasparente nello spiegare agli utenti il perche' della sua scelta (ad esempio la correttezza dei suoi calcoli potrebbe impattare sulla sicurezza degli addetti all'esperimento per cui anche se alcune WU vengono calcolate 4 o 5 volte invece che 3, gli puo' andare lo stesso bene). Tuttavia non ho seguito abbastanza i loro forum per sapere se questo e' gia' stato fatto o meno.
Stesso discorso per la valutazione della % di "computation error", nell'articolo si dice che e' piu' alta di quella di altri progetti, ma non si dice qual'e' la fonte di questa informazione. Se la fonte non e' ufficiale, cioe' non sono stati gli stessi gestori del progetto a darla, allora non vale nulla, perche' ogni utente puo' fare una statistica assolutamente parziale e dipendente dalla compatibilita' delle sue macchine contro il funzionamento di un determinato client.

In sostanza prima di dare retta ad un pinco pallino qualunque aspetterei la risposta dei gestori del server.

astroale ha scritto:

campos ha scritto:

Sono deluso, avrei accettato una politica del tipo:
100% dei crediti al primo che finisce una WU
90% al secondo,
80% al terzo e via di 10% in meno ad ogni volontario.

Non sono d'accordo chi arriva a calcolare dopo il primo ha fatto lo stesso lavoro e quindi ha diritto allo stesso riconoscimento, e infatti e' cosi' che funziona.

Non sono d'accordo neanch'io, infatti ho detto avrei accettato come giustificazione questo metodo: ho bisogno di 3 risultati su 5, i primi 3 prendono i crediti pattuiti, ma gli altri due li lascio finire ma non gli assegno il massimo, un po' di meno.

Per il resto sto alla finestra per seguire gli sviluppi della storia...

Quoto Astroale, aspetto anch'io la risposta degli amministratori del progetto... Inoltre lhc è un progetto serio e i cui risultati sono visibili da tutti, quindi non ritengo che lo sprecare la mezz'ora di tempo macchina di una wu "superflua" sia un problema... Tantopiù che volendo essere precisi i crediti si ottengono lo stesso...

Al massimo, se davvero sono wu superflue, sarebbe ausicabile una politica di abort, ma questo è l'unico cambiamento che ritengo sia da fare (sempre ripeto che non abbiano le loro ragioni per fare come fanno attualmente).

Quindi i miei continueranno a lavorare per lhc (anche perchè con quelle poche wu che arrivano è davvero uno sforzo risibile)...

Beh, ecco le risposte:

Neasan wrote:

Also the scientists are looking at the quorum and initial replication so there could be news on tha front too.

e

Your badgering doesn\'t \"shame the powers that be\" it just winds me up. We know you have misgivings about the IR minimum quorum and we have been talking to the scientists about it the new SixTrack they are working on should also to drop both of these numbers. In this case the squeaky wheel does not get the oil it merely makes the user consider walking

che nella lingua di Dante vuole più o meno dire

"Sì, siamo a conoscenza della questione e stiamo anche lavorando (coi ritmi di LHC@Home n.d.r.) per trovare una soluzione più adatta"


E qui il passaggio dove si parla di una più alta percentuale di fallimenti rispetto agli altri progetti:

Dagorath wrote:

They send out 5 copies of each task, each copy goes to a different computer. Consider those 5 to be an ad hoc temporary work group. The other 4 member are your wingmen for the mission. 5 is the Initial Replication or IR for short. They need only 3 matching results to verify that they have \"the right answer\". 3 is the minQ, short for Minimum Quorum. If they get 3 that match before you start crunching your copy, they cancel yours because it is not needed (redundant). It would be a waste of your CPU time if they didn\'t cancel it. It has nothing to do with the BOINC 6.x problem directly. The need to send out more than 3 copies is a direct result of the fact that this project has always, even before the BOINC 6.X problem, had a high rate of compute errors and results that fail to match the other results returned by members of the work group.

The cancel mechanism does not always work because the cancel order frequently does not reach your computer in time. Then you waste CPU time doing work that doesn\'t need to be done. It is far more efficient (less wasteful) to send only 3 tasks (IR = minQ) and wait until those all return and then, if the 3 don\'t match, send a fourth copy. The reason they use IR > minQ is because they know from experience that some 25% of reults will fail to match. Thus IR > minQ speeds up the completion of the batch but at the expense of precious CPU time. There are other strategies for speeding up the completion of the batch that are much more efficient. The IR > minQ strategy is an anachronism from long ago.

The Advanced Search works much better but it\'s far from perfect.

Il succo sta nel 0 crediti alle ultime WU, perchè è così? Cioè a loro non costa niente dare i crediti... comprendo e accetto il fatto delle 5 WU e solo le prime 3 necessarie, LHC è un progetto che non ha sempre lavoro disponibile, quel poco che hanno cercano di sbrigarlo rapidamente che tanto ci vuole poco e ok, ma perchè 0 crediti?

Hai capito male, i crediti te li danno lo stesso (se non ti fanno cancellare la WU prima di elaborarla), solo che il risultato che gli mandi è totalmente inutile... hanno già raggiunto il quorum

Ah già.. beh si in effetti un abort appena convalidate le 3 wu non sarebbe una cattiva idea però se uno quella WU l'ha al 90% magari preferirebbe fare il 10% rimanente e riceverne i crediti... questione u pò ostica, però siccome le WU sono poche direi che è il problema minore

Credo che abbiano lasciato la possibilità di elaborare e non abortire proprio perchà se la WU è iniziata e si abortisce allora sì che si è perso del tempo. Se i crediti vengono pagati come al primo anche per gli ultimi 2 dov'è il problema? Hai usato del tempo non dedicandolo ad altro?
Solo ultimamente nelle rare WU che arrivano i tempi (per me) sono sopra l'ora/ora e mezza, ma quando fino a qualche mese fa andava più o meno a pieno regime le WU erano molto brevi, dunque avere sprecato dieci minuti non mi sembra una grande tragedia.

Giopro ha scritto:

Credo che abbiano lasciato la possibilità di elaborare e non abortire proprio perchà se la WU è iniziata e si abortisce allora sì che si è perso del tempo. Se i crediti vengono pagati come al primo anche per gli ultimi 2 dov'è il problema? Hai usato del tempo non dedicandolo ad altro?
Solo ultimamente nelle rare WU che arrivano i tempi (per me) sono sopra l'ora/ora e mezza, ma quando fino a qualche mese fa andava più o meno a pieno regime le WU erano molto brevi, dunque avere sprecato dieci minuti non mi sembra una grande tragedia.

il problema credo sia nel principio..
io come volontario non voglio sprecare neanche mezzo secondo CPU nell'elaborazione di cose inutili..
chissenefrega se mi danno o meno i crediti..

come è stato suggerito, la soluzione è nello spedire 3 WU alla volta.
se i risultati non sono congruenti se ne spedisce una quarta e così via..
è il server del progetto che deve 'sprecare' il suo tempo, non il pc di un volontario..

Ripensandoci, non è solo LHC che funziona così, a me è capitato, ultimamente, di avere elaborato delle WU con Seti e al momento del collegamento con il server me le abbia rifiutate perchè il risultato era già stato raggiunto. L'ho presa con filosofia

Nel caso di LHC l'ho settato in modo da collegarsi sempre con il server e chiedere, anche se a volte passano ore tra un collegamento e l'altro; Seti faccio il collegamento manuale. Però se quando si collega i risultati degli altri computer non sono ancora giunti sul server e sono così sfortunato che verranno caricati dopo pochi minuti, il server non può colleagrsi al mio pc e dirgli di smettere di elaborare alcune WU. Mi sembra che Boinc non agisca in questo modo e, quindi, a meno di cambiare il modo di agire permettendogli di contattare tutti i pc del mondo (penso altamente impossibile) mi sa che la situazione rimane così.

SETI non è come LHC, non so cosa ti sia successo, ma su SETI tutte le WU contano

Appena successo con 12 wu di SetiBeta:

30/12/2008 23.54.05|SETI@home Beta Test|Message from server: Completed result 23ap08ab.26580.20931.4.11.143_2 refused: result already reported as success
30/12/2008 23.54.05|SETI@home Beta Test|Message from server: Completed result 23ap08ab.26580.19295.4.11.17_2 refused: result already reported as success
30/12/2008 23.54.05|SETI@home Beta Test|Message from server: Completed result 23ap08ab.26580.21340.4.11.225_2 refused: result already reported as success
30/12/2008 23.54.05|SETI@home Beta Test|Message from server: Completed result 23ap08ab.26580.21340.4.11.243_2 refused: result already reported as success
30/12/2008 23.54.05|SETI@home Beta Test|Message from server: Completed result 23ap08ab.26580.19295.4.11.145_2 refused: result already reported as success
30/12/2008 23.54.05|SETI@home Beta Test|Message from server: Completed result 23ap08ab.26580.21340.4.11.96_2 refused: result already reported as success
30/12/2008 23.54.05|SETI@home Beta Test|Message from server: Completed result 23ap08ab.26580.21340.4.11.66_2 refused: result already reported as success
30/12/2008 23.54.05|SETI@home Beta Test|Message from server: Completed result 23ap08ab.26580.20522.4.11.98_2 refused: result already reported as success
30/12/2008 23.54.05|SETI@home Beta Test|Message from server: Completed result 23ap08ab.26580.20931.4.11.12_2 refused: result already reported as success
30/12/2008 23.54.05|SETI@home Beta Test|Message from server: Completed result 23ap08ab.26580.17659.4.11.227_2 refused: result already reported as success
30/12/2008 23.54.05|SETI@home Beta Test|Message from server: Completed result 23ap08ab.26580.21340.4.11.153_2 refused: result already reported as success
30/12/2008 23.54.05|SETI@home Beta Test|Message from server: Completed result 23ap08ab.26580.16841.4.11.225_2 refused: result already reported as success

Tenendo conto che le ho fatte andare con l'applicazione ottimizzata, il tempo impiegato è di circa 50 minuti l'una. Tutto tempo sprecato

Tenendo conto che è SETI BETA, specifichiamo BETA (casomai non si fosse capito, è BETA), ne deduciamo che, essendo un progetto BETA, queste cose siano volute Sarà per aver più in fretta i risultati, tanto loro non è che devono elaborar dati, il loro scopo è testare, in fretta, i client nuovi

Su SETI normale non è così