ARGOMENTO:

Nub , mi sembra che WCG continua ad avanzare con le stats , avevo chiuso in sesta posizione e ora sono in ottava

sabayonino ha scritto:

Nub , mi sembra che WCG continua ad avanzare con le stats , avevo chiuso in sesta posizione e ora sono in ottava

No. Il "challenge" WCG è terminato alle 02:00 del 10/05 regolarmente.
boincrankings.eu5.org/penta17/userdata/2/

Avrai fatto male i conti.

hanno annunciato anche l'ultima disciplina: yoyo, dal 13 al 16 maggio.

Quest`anno il Pentatlon proprio non mi ispira...

@gatto, mi sembra che la tua risposta debba avere maggiori spiegazioni.

In ogni caso si tratta di dirottare le proprie forze, per un breve periodo, dai propri progetti preferiti ad altri, che mi sembrano altrettanto lodevoli

GBI ci ha raggiunti

sabayonino ha scritto:

GBI ci ha raggiunti

un grande gruppo Italiano forte e coeso...
einsteinathome.org/community/teams/207125
...composto da un solo membro

sabayonino ha scritto:

GBI ci ha raggiunti

Si sa chi sia questo gruppo? Perchè a quanto vedo c'è solo l'utente GIPICS...
L'unica spiegazione per la potenza enorme che dispone, è che sia un'azienda o simili

Dalla descrizione del gruppo risulta questo:

[...]Il nostro scopo è quello di costituire un unico e potente user capace di imporsi nel mondo dell'elaborazione.[...]

La cosa mi è ancora meno chiara di prima...

corla99 ha scritto:

sabayonino ha scritto:

GBI ci ha raggiunti

Si sa chi sia questo gruppo? Perchè a quanto vedo c'è solo l'utente GIPICS...
L'unica spiegazione per la potenza enorme che dispone, è che sia un'azienda o simili

questa la potenza di fuoco impiegata su LHC: lhcathomeclassic.cern.ch/sixtrack/hosts_user.php?userid=504705
negli altri progetti hanno nascosto le macchine, mi auguro che siano qualcuna in più altrimenti siamo veramente messi male come team per farci suonare così
Leggendo la descrizione del team sembra che raccolgano sotto lo stesso utente i computer dei partecipanti; di sicuro è un gruppo recente visto che la prima registrazione ad un progetto l'hanno fatta meno di 3 settimane fa, come si può vedere ad esempio qui: pogs.theskynet.org/pogs/show_user.php?userid=455333

mugnaio ha scritto:

questa la potenza di fuoco impiegata su LHC: lhcathomeclassic.cern.ch/sixtrack/hosts_user.php?userid=504705

Non riesco a vederli.

Intendi qualcosa tipo questo?

Su LHC@home sto elaborando soltanto Sixtrack, ma ho notato che la paga è davvero bassa (20-25cr/h) su i7, Linux. Questa scelta è un po' obbligata dalla scarsa banda dell'adsl casalinga.
Qualcuno elabora anche Atlas, vLHC e LHCb? Va meglio, vero? Ho visto dei top host i7 che fanno almeno 20k al giorno eseguendo Atlas multithreading, però su Windows.

mica tanto

per esempio mi capita con le LCHb che riesco a farne girare una sola (nel senso che questa avanza), mentre le altre sono sempre in running ma con la % a 0.00 !!!!

e devo annullare tutte le altre LHCb che ho in bunker

e poi c'è il problema che tutte le WUs con la VBox hanno deadline di quasi un mese e oltre, e quindi risultano non funzionali per il challenge

PS ho detto una sciocchezza. le WU con VBox hanno quorum 1 !!!!

Sì, infatti. Le CMS e le Theory hanno quorum=1 e anche le ATLAS mt, che in più sono relativamente brevi. Devo provare queste ultime su un PC connesso wireless, ma a pochi metri da router principale.

Le LHCb mi hanno sempre dato problemi in passato per cui le eviterei. Le Theory e CMS invece dovrebbero essere abbastanza stabili, soprattutto le Theory, però non ce la faccio con la mia adsl a "feedare" una una decina di VM.

Nubman ha scritto:

Non riesco a vederli.

Intendi qualcosa tipo questo?

più o meno...


sarà un caso che su lhc i computer sono stati nascosti dopo il mio post... oppure salutiamo i cugini ?

per quanto riguarda lhc su virtualbox, io sono impazzito qualche mese fa con le Atlas: una su quattro andava avanti all'infinito, poi ho scoperto che con un reset manuale della vm ripartiva e finiva in tempi normali. A memoria le altre sono più stabili.

Una bella rottura le lhc per virtualbox, molto spesso le trovi che si girano i pollici. A volte se le sospendi poi quando ripartono concludono e vengono validate. Altre le riavvii ma non cambia niente, poi comunque quando terminano sono valide.
Invece le atlas che avevo sono andate lisce come l'olio ma quando le ho riportate non erano valide. Eppure qualche settimana fa quando giravano nel progetto separato ne ho fatte parecchie senza problemi.
Sempre qualche settimana fa le cms terminavano dopo 10 minuti senza aver fatto niente perché non c'era lavoro e non scaricavano niente.
Bello ma ci vuole passione

Quello che posso dire per esperienza di smanettamenti passati è:

-quando le Atlas vanno all'infinito è a causa di un Kernel Panic nell'OS della VM (dal BOINC Manager o Virtualbox si può vedere); infatti, il ravvio della VM, come ha detto Mugnaio risolve
-le Theory (ma mi pare anche le CMS) hanno un tempo massimo di esecuzione fissato sui 64800s (18h); agendo manualmente sul file xml dei checkpoint (nello slot dedicato alla wu da BOINC) a VM spenta, si può fissare un tempo vicino a quello massimo (es. 64780s), facendole terminare prima; raramente facendo ciò vanno in errore di calcolo il che significa niente cobblestones/crediti, ma per fortuna il lavoro figura su MCPlots perché i job vengono consegnati vita natural durante
-meglio usare sempre l'ultima versione di Virtualbox con l'Extension Pack aggiornato (su Linux)

Molti problemi, comunque sia, derivano dal network proprio o del CERN. A volte una adsl scarsa di banda può portare al fallimento di qualche download fondamentale per l'inizializzazione dei task. Altre volte il CERN ha problemi temporanei, per es. non vengono generati i job per la VM.

Sì sì, complicato. Meglio girare di Sixtrack.
E io aggiungo questa: a me su alcuni client arrivano anche wu per l'applicazione senza plan_class (cioè né sse2 né pni) o per architettura i686-pc-linux-gnu. Quella senza plan_class è lentissima. Stavolta sto riassegnando manualmente le applicazioni con la tecnica appresa dal forum del progetto SETI, ma in passato avevo messo a punto un app_info.xml per forzare il progetto a mandarmi lavoro per l'applicazione sse2. Mi pare che sul client principale ho risolto con il tag no_alt_platform nel cc_config.xml, perché lì mi arrivano tutte giuste. Boh, sono stanco di vivere.

@Mugnaio: ottimo screenshot! Eventualmente possiamo esplorare i top host degli altri progetti per trovarne qualcuno. Da fare nei giorni di pioggia quando si è tappati in casa, ma anche no.

Il trucchetto dei 64780s va bene anche per le lhcb

Io sto avendo tanti di quei problemi...
su un i5 ho trovato 4 wu di yoyo che dopo 8 ore erano bloccate al 20%, wu di lhc sixtrack che su un i7 ci mettono non meno di 9 ore e mezza...
il tutto unito alla mia nubbaggine...

corla99 ha scritto:

Io sto avendo tanti di quei problemi...
su un i5 ho trovato 4 wu di yoyo che dopo 8 ore erano bloccate al 20%, wu di lhc sixtrack che su un i7 ci mettono non meno di 9 ore e mezza...
il tutto unito alla mia nubbaggine...

non è detto che siano problemi: ho visto decine wu di yoyo (ecm per la precisione) durare un'ora e altre decine durare più di 20 ore, con checkpoint e conseguente variazione della percentuale completata dopo 5-6 ore (il motivo per cui elaboro su yoyo solo quando sono sicuro di essere 24x7 su quel progetto).
Per quanto riguarda sixtrack, ero abituato a wu da 8 secondi fino a max 2 ore, ma sullo xeon le ho prese tutte da più di 8 ore (e con la scorta che ho fatto non so se riesco a finirle prima della scadenza).