ARGOMENTO:

zio, ma la locandina va bene? La pubblichiamo in homepage?

è già stata messa in home

zioriga ha scritto:

è già stata messa in home

..e avevo anche guardato
Grazie

zioriga ha scritto:

un'altra info per chi vuol fare scorta.

la deadline del progetto è di 14 giorni, per cui si può incomincaire a fare scorta da lunedì 14 dopo le ore 17.00

Non so per quale ignoto motivo avevo pensato che il giorno di inizio scorta fosse il 21, meno male che lo hai scritto.

Avrei voluto cominciare con ramdisk, ma temo che dovrò desistere perché non ho ancora comprato l'hardware necessario e 8gb di ram dovrebbero essere strettini. Mmmm... qualche prova si può fare.

Non so se stai preparando una classifica basata sulla lettura del solito xml. Volendo, non c'è bisogno di far nulla.
Classifica challenge: boincrankings.eu5.or...php?ChallengeId=744&TeamName=BOINC.Italy
P.S. l'errore presente in questo momento è assolutamente normale. Scomparirà a inizio challenge.

va benissimo il tuo lavoro !!!
anche perchè Rick, che mi aveva promesso che avrebbe fatto una procedura per farmi azionare io il lavoro che lui aveva fatto, non si è pi9ù fatto sentire.
Direi proprio che si sia stufato del calcolo distribuito e di BOINC.Italy

sul discorso della RAM, o client multiplo in RAM, direi che non serva proprio a niente.
sto tenendo sotto controllo l'utilizzo del disco da parte del progetto Rosetta, ma direi che sia quasi trascurabile

zioriga ha scritto:

sul discorso della RAM, o client multiplo in RAM, direi che non serva proprio a niente.
sto tenendo sotto controllo l'utilizzo del disco da parte del progetto Rosetta, ma direi che sia quasi trascurabile

Quanto spazio viene scritto durante l'intera esecuzione di una wu? Hai un valore medio per 1 ora di esecuzione? (es. in 1 ora l'app scrive totalmente 800mb)

Edit: ho controllato con 'iotop' e in effetti la velocità di scrittura di picco è intorno ai 400kb/s. Le restanti rilevazioni sono per lo più velocità comprese tra 0 e 70kb/s. Quindi, nel caso peggiore (velocità di scrittura costantemente sui 400kb/s da dividere per 8 thread) l'app scrive 175,8mb, ovvero hai ragione tu. Solamente all'avvio vengono scritti circa 400mb tutti insieme, ma sempre una inezia rimane.

Curioso che alcune wu finiscano prima nonostante abbia impostato 12h di durata.



P.S. ho scaricato tutte le wu che ho nel client il giorno dopo aver aggiornato il sito. Quindi, è da escludersi che alcune wu fossero impostate sulla durata precedente (default).

[Edit] Ahiahi, sembra che un motivo ci sia. Tutte le wu terminate prima hanno raggiunto i 99 decoys!!!

Nubman ha scritto:

Curioso che alcune wu finiscano prima nonostante abbia impostato 12h di durata.

P.S. ho scaricato tutte le wu che ho nel client il giorno dopo aver aggiornato il sito. Quindi, è da escludersi che alcune wu fossero impostate sulla durata precedente (default).

[Edit] Ahiahi, sembra che un motivo ci sia. Tutte le wu terminate prima hanno raggiunto i 99 decoys!!!

@Nub: io scaccolo quelle da 16 ore, molte volte dopo 7 ore son già terminate al 100%, penso che quando decidi di scaccolare quelle da 12 ore, indichi che tu sei disposto a ricevere wu di lunghezza "fino a"...12 ore.

Ci si vede al challange

Di fatto succede quello che dici tu, ma non penso debba andare così. Se va così, ovviamente è stato lo staff a scegliere che vada in questo modo. Vabbè...

Se non hai mai guardato l'output di una wu di Rosetta, controlla. Noterai che l'app esegue una specie di task(s) dentro al task chiamati decoy(s). C'è proprio un contatore nell'output. Può succedere che un decoy sia così lungo da richiedere 30000s (mi è capitato) da solo. Altre volte ne vengono eseguiti parecchi. Non sembra essere un caso che tutte le wu che sono terminate prima delle 12 ore si siano fermate ai 99 decoy(s), numero che sembrerebbe essere il limite preimpostato per la app di questo progetto... il che manda a farsi benedire ogni stima per fare bunker. Bisognerà scaricare lavoro per difetto, un grande difetto (io userò il valore 6h per contare quante wu mi servono).

devo correggere quanto detto in precedenza.
sembrerebbe che anche con Rosetta funzionino i client multipli.
o meglio, ho provato a generare un nuovo client in RAM e gli viene assegnato un hostID differente da quello creato su HD.

precedentemente quelli che creavo su HD avevano tutto lo stesso hostID e pertanto andava ogni volta tutto perduto (client detached)

Se per caso andrò corto su HD provero a riutilizzare questo client su RAM

zioriga ha scritto:

devo correggere quanto detto in precedenza.
sembrerebbe che anche con Rosetta funzionino i client multipli.
o meglio, ho provato a generare un nuovo client in RAM e gli viene assegnato un hostID differente da quello creato su HD.

precedentemente quelli che creavo su HD avevano tutto lo stesso hostID e pertanto andava ogni volta tutto perduto (client detached)

Se per caso andrò corto su HD provero a riutilizzare questo client su RAM

Non è un po' rischioso? Potresti perdere il lavoro fatto nel caso dovesse spegnersi il pc.
Non è che al progetto basta che una partizione diferente su HD per sdoppiare il client?

in ambiente Windows, non c'è pericolo.
il programma, gratuito, softperfect RAM Disk, può effettuare salvataggio su HD secondo una frequenza, scelta da utente, che può variare di 5 in 5 minuti.

zioriga ha scritto:

in ambiente Windows, non c'è pericolo.
il programma, gratuito, softperfect RAM Disk, può effettuare salvataggio su HD secondo una frequenza, scelta da utente, che può variare di 5 in 5 minuti.

Sì, ma il problema non del tutto è risolto (volendo pure su linux si 'resynca' il contenuto da qualche parte). Può essere che il client avviato nuovamente veda il ram disk come un nuovo hard disk? L'id rimarrà lo stesso? In linea di massima dovrebbe funzionare, ma cosa succede se si montano due ram disk e si avviano due client multipli?

direi che il problema non sussista.
al massimo è sufficiente un client ulteriore. in altre parole; 1 su HD ed eventualmente uno su RAM

zioriga ha scritto:

direi che il problema non sussista.
al massimo è sufficiente un client ulteriore. in altre parole; 1 su HD ed eventualmente uno su RAM

Sì, meglio usarlo quando si è alle strette e senza abusarne, almeno fin quando non si capisce la logica sottostante.

Intanto Rosetta insiste nel consegnarmi qualche task con scadenza = 4gg.
Ieri su un pc mi sono beccato una workunit con scadenza 2gg.
A parte queste anomalie la deadline di 14gg viene rispettata.

Il problema è abbastanza curioso. Primo download su un altro pc: 28wu scadenti il 18 dicembre, 2 wu scadenti il 28 dicembre. Di questo passo non so quando riuscirò ad effettuare un download massiccio per il challenge. Non sono contento di dover annullare wu che probabilmente mi vengono 'recapitate' in quanto urgenti, ma non ho alternative. Mettiamo che una persona deve partire per le ferie... il problema sarebbe lo stesso.

Parto con download bunker

Sto annullando una marea di wu, in effetti non è molto sostenibile come cosa senza uno script.

Server status: "Ready to send 37,260"
Mettiamo che la metà hanno scadenza ravvicinata?


A ppost!

14-Dec-2015 17:55:35 [rosetta@home] No work sent
14-Dec-2015 17:55:35 [rosetta@home] (reached daily quota of 32 results)

Preferisco non aumentare le ncpus per ora.

[edit] per rialzare il daily quota è stato sufficiente switchare a 1 ora la durata delle wu, aggiornare dal progetto e riavviare boinc. Tutte le wu sono terminate con successo e una volta consegnate il parametro max daily ecc... è risalito a 100 (cioè 800 results). Posso riprendere il download, fiuuuu! forse per i più sarà una banalita, ma conviene annullare tutte le wu che non servono SOLTANTO alla fine.

Nubman ha scritto:

[edit] per rialzare il daily quota è stato sufficiente switchare a 1 ora la durata delle wu, aggiornare dal progetto e riavviare boinc. Tutte le wu sono terminate con successo e una volta consegnate il parametro max daily ecc... è risalito a 100 (cioè 800 results). Posso riprendere il download, fiuuuu! forse per i più sarà una banalita, ma conviene annullare tutte le wu che non servono SOLTANTO alla fine.

Scusa mi spiegheresti come si fa?
Sto cercando di fare scorta, purtroppo me ne arrivano troppe con scadenza prima dell'inizio del challenge.

Kree ha scritto:

Nubman ha scritto:

[edit] per rialzare il daily quota è stato sufficiente switchare a 1 ora la durata delle wu, aggiornare dal progetto e riavviare boinc. Tutte le wu sono terminate con successo e una volta consegnate il parametro max daily ecc... è risalito a 100 (cioè 800 results). Posso riprendere il download, fiuuuu! forse per i più sarà una banalita, ma conviene annullare tutte le wu che non servono SOLTANTO alla fine.

Scusa mi spiegheresti come si fa?
Sto cercando di fare scorta, purtroppo me ne arrivano troppe con scadenza prima dell'inizio del challenge.

Praticamente quando annulli delle workunit ti abbassano la daily quota. Questo comportamento del server è una sorta di prevenzione per i computer che restituiscono troppi errori. Quindi, è abbastanza importante non annullare alcuna workunit mentre si fa scorta.

Fatta questa premessa... ti scrivo la procedura che metterei in atto io.

1) Alzare la riserva minima/massima a 10 giorni.
2) Dal sito impostare come durata delle workunit 1 ora. In questo modo, nel frattempo che si fa scorta, sarà possibile anche elaborare le prime wu della lista e magari consegnarne qualcuna prima di dover annullare le wu non utili per la scorta. Ciò permetterà anche di alzare la daily quota non appena si consegnano i risultati. Leggevo da qualche parte che la daily quota per ogni risultato completato correttamente si alza di un fattore 2.
3) Fare update del progetto cliccando sull'apposito pulsante di BOINC (in questo modo ogni workunit avviata durerà quanto stabilito sul sito). Se si hanno delle wu di Rosetta in corso da più di 1 ora, riavviare il client. In questo modo dovrebbero terminare immediatamente al riavvio.
4) Scaricare le workunit e, se occorre, alzare il valore del parametro ncpus mediante il file cc_config.xml per scaricare più lavoro ancora (comunque non si potrà andare oltre la daily quota massima che dovrebbe essere 100 workunit per ogni thread del processore).
5) Quando si è raggiunto un numero soddisfacente di workunit con la scadenza oltre la data di inizio del challenge, dal sito si può rialzare la durata delle workunit con un valore alto come 8, 12, 24 ore... quindi, fare update del progetto.
6) Annullare tutte le wu con la scadenza prima del challenge e reportarle. Bloccare il network e riavviare boinc.

Ora si può finalmente elaborare la scorta offline.