Gestione della cache: urgente!

[lucab76]

Sto riscontrando non poche difficoltà a far ragionare il BOINC Manager (il nuovo 5.8.8) per la gestione della cache. Mi spiego.

- Ho impostato nelle preferenze un buffer di 7.5 giorni per fare scorta delle WUs di SIMAP.
- Ho sospeso tutti i progetti sulla macchina (Suspended, No new task), tranne, ovviamente, SIMAP!
- Ho resettato i debiti a lungo e a breve termine sulla macchina.
- Ho impostato a 1 tutti i resource share dei progetti diversi da SIMAP, mentre ho impostato a 1000 quello di SIMAP.
- Non ho WUs di altri progetti in cache.

Nonostante questo... non c'è verso di scaricare nuove WUs. Ma la coda di elaborazione è molto inferiore al buffer richiesto: infatti ho 72 WUs da 2h ciascuna, ma elaborando due task alla volta in 72h le finisco, quindi in 3 giorni... e gli altri 4.5 giorni di cache che gli ho chiesto? Perchè il BOINC Manager non chiede altro lavoro?

Da notare che non ho problemi di spazio su disco, non ho raggiunto il numero massimo di WUs consentite in un giorno (150 WUs per ogni CPU), su SIMAP ci sono WUs da scaricare, la macchina non è in panic-mode (e vorrei vedere!!) e non ho file di preferenze in locale.

Ho letto che con il nuovo Manager sono cambiate le politiche di scheduling, ma non ho trovato ulteriori dettagli. Ma non dovrebbe essere difficile per il BOINC Manager capire cosa c'è da fare... Voglio WUs!!

In compenso... attenzione, attenzione... nel fare un update di Einstein per aggiornare il resource share e con il progetto Suspended e No New Task... il BOINC Manager cos'ha fatto? Ha scaricato la nuova applicazione e una 30ina di WUs da 8 ore l'una! Ma chi gli ha chiesto nulla!!

Sidenote: Da come si è comportato il caro Manager, parrebbe che dei debiti a lungo termine non se ne faccia più di nulla... Infatti ha scaricato tutta quella mole di WUs di Einstein con i debiti azzerati... e poi non ha aggiornato i debiti in favore di SIMAP dopo il download... e avrebbe dovuto farlo...

Sarà stato sinadex a crackarmi il Manager per bloccare le mie elaborazioni ed agevolarsi il sorpasso?

Accetto pareri e consigli , astenersi perditempo!
BOINC Geeks needed!

[lucab76]

Ho dimenticato di aggiungere queste annotazioni del client_state.xml:
<on_frac>0.792576</on_frac>
<active_frac>0.997625</active_frac>
<cpu_efficiency>0.978744</cpu_efficiency>
che sono ovviamente importanti, perchè determinano quanto sta accesa la macchina e quanto si impegna nel calcolo...

Considerando anche queste e facendo il prodotto dei coefficienti (0,773887) almeno a 7.5 * 0,773887 = 5.8 giorni dovrebbe arrivarci ... invece non si supera i 3 giorni di coda di elaborazione...

Ho provato anche a seguire le guidelines sulle politiche di Work Fetch adottate e rilasciate da BOINC a questo indirizzo A me parrebbe tutto in regola!

[GHz]

Sinceramente, non so cosa abbiano cambiato di preciso nel nuovo cpu-scheduler, non mi sono mai messo a fare i conti precisi come fai te Se riesci a scoprire qualcosa illuminaci

Ps: ti consiglio l'iscrizione alla ML boinc_dev

Ciao,
GHz

[lucab76]

La faccenda è grave! 'sto scheduler dà i numeri!
Leggete i dettagli in questa discussione... ci sono cosettine interessanti!
Poi semmai vi faccio un riassunto... appena riesco a capirci qualcosa!!

Torno a col Boinc Manager!

[lucab76]

Originariamente inviato da lucab76

La faccenda è grave! 'sto scheduler dà i numeri!

Mi quoto e mi correggo:
Questo nuovo scheduler è PAZZO!
Ma proprio di fuori come i terrazzi , anzi [Tuscany mode on]è proprio di fòri 'ome 'e terrazzi![Tuscany mode off]

Appena qualcuno a Berkeley me ne dà conferma, vi informo per benino!
A dopo!

[Il Capitano]

Incollo qui un pVT di sweethawk (non puo' scrivere perche' e' sospeso )

06/02/2007 10.41.12|Einstein@Home|Starting task h1_0448.0_S5R1__3290_S5RIa_0 using einstein_S5RI version 424
06/02/2007 10.41.14|Einstein@Home|[file_xfer] Started upload of file h1_0448.0_S5R1__3292_S5RIa_0_0
06/02/2007 10.41.38|Einstein@Home|[file_xfer] Finished upload of file h1_0448.0_S5R1__3292_S5RIa_0_0
06/02/2007 10.41.38|Einstein@Home|[file_xfer] Throughput 5807 bytes/sec
06/02/2007 10.41.40|Einstein@Home|Sending scheduler request: To report completed tasks
06/02/2007 10.41.40|Einstein@Home|Reporting 1 tasks
06/02/2007 10.41.45|Einstein@Home|Scheduler RPC succeeded [server version 505]
06/02/2007 10.41.45|Einstein@Home|Deferring communication for 1 min 0 sec
06/02/2007 10.41.45|Einstein@Home|Reason: requested by project
06/02/2007 11.32.10|Einstein@Home|Computation for task h1_0448.0_S5R1__3291_S5RIa_0 finished
06/02/2007 11.32.10|Einstein@Home|Starting h1_0448.0_S5R1__3289_S5RIa_0
06/02/2007 11.32.10|Einstein@Home|Starting task h1_0448.0_S5R1__3289_S5RIa_0 using einstein_S5RI version 424
06/02/2007 11.32.12|Einstein@Home|[file_xfer] Started upload of file h1_0448.0_S5R1__3291_S5RIa_0_0
06/02/2007 11.32.26|Einstein@Home|[file_xfer] Finished upload of file h1_0448.0_S5R1__3291_S5RIa_0_0
06/02/2007 11.32.26|Einstein@Home|[file_xfer] Throughput 10849 bytes/sec
06/02/2007 11.32.32|Einstein@Home|Sending scheduler request: To report completed tasks
06/02/2007 11.32.32|Einstein@Home|Reporting 1 tasks
06/02/2007 11.32.37|Einstein@Home|Scheduler RPC succeeded [server version 505]
06/02/2007 11.32.37|Einstein@Home|Deferring communication for 1 min 0 sec
06/02/2007 11.32.37|Einstein@Home|Reason: requested by project
06/02/2007 12.10.18|Einstein@Home|Computation for task h1_0448.0_S5R1__3290_S5RIa_0 finished
06/02/2007 12.10.18|Einstein@Home|Starting h1_0448.0_S5R1__3288_S5RIa_0
06/02/2007 12.10.18|Einstein@Home|Starting task h1_0448.0_S5R1__3288_S5RIa_0 using einstein_S5RI version 424
06/02/2007 12.10.20|Einstein@Home|[file_xfer] Started upload of file h1_0448.0_S5R1__3290_S5RIa_0_0
06/02/2007 12.10.46|Einstein@Home|[file_xfer] Finished upload of file h1_0448.0_S5R1__3290_S5RIa_0_0
06/02/2007 12.10.46|Einstein@Home|[file_xfer] Throughput 6403 bytes/sec
06/02/2007 12.10.47|Einstein@Home|Sending scheduler request: To report completed tasks
06/02/2007 12.10.47|Einstein@Home|Reporting 1 tasks
06/02/2007 12.10.57|Einstein@Home|Scheduler RPC succeeded [server version 505]
06/02/2007 12.10.57|Einstein@Home|Deferring communication for 1 min 0 sec
06/02/2007 12.10.57|Einstein@Home|Reason: requested by project
06/02/2007 13.02.50|Einstein@Home|Computation for task h1_0448.0_S5R1__3289_S5RIa_0 finished
06/02/2007 13.02.50|Einstein@Home|Starting l1_0403.5_S5R1__379_S5RIa_0
06/02/2007 13.02.50|Einstein@Home|Starting task l1_0403.5_S5R1__379_S5RIa_0 using einstein_S5RI version 424
06/02/2007 13.02.53|Einstein@Home|[file_xfer] Started upload of file h1_0448.0_S5R1__3289_S5RIa_0_0
06/02/2007 13.05.36|Einstein@Home|[file_xfer] Finished upload of file h1_0448.0_S5R1__3289_S5RIa_0_0
06/02/2007 13.05.36|Einstein@Home|[file_xfer] Throughput 780 bytes/sec
06/02/2007 13.05.40|Einstein@Home|Sending scheduler request: To report completed tasks
06/02/2007 13.05.40|Einstein@Home|Reporting 1 tasks
06/02/2007 13.06.06|Einstein@Home|Scheduler RPC succeeded [server version 505]
06/02/2007 13.06.06|Einstein@Home|Deferring communication for 1 min 0 sec
06/02/2007 13.06.06|Einstein@Home|Reason: requested by project



Ho BOINC 5.8.8 con solo Einstein, versione 4.24


Sto finendo velocemente le scorte.

Credo che sia lo stesso problema vero? Il suo problema e' che non scarica piu' nuove WU.
Per aggirare momentaneamente il problema, l'unica sarebbe tornare alla versione 5.4.9, vero?

[lucab76]

Dal log non si vede niente di strano, solo le normali procedure di up dei risultati.
Se non chiede altro lavoro, potrebbe avere il mio stesso problema: se la cache è impostata su un valore troppo alto, lo scheduler va in allarme e non scarica.

Ora, so che può sembrare assurdo, ma digli di abbassare la cache!

A causa di come è scritta la formula che calcola se sei o no a rischio di deadline, se imposti una cache troppo alta, anche se non hai WUs in cache, lui chiude i rubinetti.

Quindi mandalo sulla pagina dell'account, digli di abbassare la cache di un giorno alla volta e fagli fare l'update del Manager, fino a che questo non inizia a scaricare di nuovo.

Oh My God... Ma sweethawk è nella Flotta... quindi niente regolazioni sulla cache!

Allora direi... avanti tutta fino a fine cache con Einstein in "No New Work". Poi defenestra il 5.8, reinstalla il 5.4.11 e fa un bel reset del progetto. Mi raccomando... cache vuota o spuXXana le poche WUs rimaste!

[Il Capitano]

E ti pareva. abbiamo beccato l'unico caso in cui unaccount multiplo crea problemi
Grazie lucab credo anch'io che il problema sia quello stesso tuo, infatti la flotta ha la cache al massimo, cioe' 10 giorni .
Ok mi ritiro nel nostro thread per deliberare una soluzione

[lucab76]

Beh, però può sempre usare il global_prefs_override.xml.

1) Vai nella cartella di Boinc e ti fai una copia del global_prefs.xml;
2) Lo ridenomini in global_prefs_override.xml;
3) Lo modifichi togliendo i tag
<source_project>...</source_project>
<source_scheduler>...</source_scheduler>
<mod_time>...</mod_time>;
4) Modifichi il valore di
<work_buf_min_days>...</work_buf_min_days>;
5) Lo salvi;
6) Dal Manger dai Advanced -> Read local prefs file;
7) Update di Einstein;

Ovviamente ripeti da 4) a 7) fino a che non scarica di nuovo!

[djtux]

Soluzione drastica ma efficace: fare il reset del progetto dopo aver (nel mio caso) aumentato la cache. Su SIMAP avevo la cache a 1 giorno e mi sono arrivate 5 wu. L'ho aumentata a 2 ma non mi arrivavano nuove wu. Ho fatto il reset e me ne sono arrivate 15 nuove nuove!

[lucab76]

In realtà non hai risolto il problema!
Tra le WUs che hai buttato via e l'aumento del buffer... non hai convinto lo scheduler che potevi tranquillamente ricevere altro lavoro... gli hai semplicemente detto: "Oh, io sono senza lavoro... fai un po' te!!".

Il vero problema è fargli capire che se aumenti il work buffer richiesto, è perchè vuoi un maggior numero di WUs. Lui però ragiona al contrario! E pensa: "Vuoi un buffer più grande? Allora sei più vicino alla scadenza! Allora a te, niente lavoro!"

I miei complimenti a chi ha sviluppato il nuovo dement-scheduler! E chissà quanto c'avranno studiato sopra!!
Unico commento:

[Il Capitano]

Originariamente inviato da lucab76

Beh, però può sempre usare il global_prefs_override.xml.

1) Vai nella cartella di Boinc e ti fai una copia del global_prefs.xml;
2) Lo ridenomini in global_prefs_override.xml;
3) Lo modifichi togliendo i tag
<source_project>...</source_project>
<source_scheduler>...</source_scheduler>
<mod_time>...</mod_time>;
4) Modifichi il valore di
<work_buf_min_days>...</work_buf_min_days>;
5) Lo salvi;
6) Dal Manger dai Advanced -> Read local prefs file;
7) Update di Einstein;

Ovviamente ripeti da 4) a 7) fino a che non scarica di nuovo!

Al punto 4, che valore consigli di mettere?

[lucab76]

Originariamente inviato da Il Capitano

Al punto 4, che valore consigli di mettere?

Se la deadline su Einstein è ancora impostata a 14 giorni, prova a mettere 6-7.
Se fosse 10 giorni, prova 4-5.

[lucab76]

Tenete conto questo importante fatto:
- La 5.4.11 usava i giorni di cache in questo modo: hai impostato 10gg? Bene, io ti dò 10gg di lavoro per ogni progetto a cui partecipi (sempre tenendo conto dei debiti a lungo termine, del tempo di attività della macchina, delle risorse dedicate ad ogni progetto, ecc.).
- La 5.8.8 usa i giorni di cache in modo diverso: hai impostato 10gg? Bene, io ti dò 10gg di lavoro tra tutti i progetti a cui partecipi.

Quindi a parità di cache, il lavoro disponibile per ogni progetto è destinato a calare in base al numero di progetti su cui è attaccata la macchina. Se avete un solo progetto attivo, vi ritrovere "solo" a dover gestire l'assurda regola della deadline. Se invece lavorate su due progetti, avrete una cache di 5gg per entrambi; su tre progetti, cache di 3,33gg per ognuno; e via di questo passo!

Qualcuno deve essersi lamentato degli utenti che facevano incetta di WUs per poi annullarle perchè scadute! E gli sviluppatori hanno preso queste drastiche contromisure!

[lucab76]

Altro bug inquietante... tanto per cambiare!

Dunque, quello schifo di scheduler, per funzionare, ha bisogno di sapere quanto ci mette un utente ad elaborare una WUs. In base a questo dato e in base a quanti secondi di lavoro sta per chiedere, si calcola il numero di nuove Wus da scaricare.

Per tenere aggiornato il tempo di elaborazione, lui ne dà una stima iniziale in base ai benchmarks, poi lo corregge alla fine dell'elaborazione di ogni WUs. Per approssimazioni successive, arriva ad un valore, si assesta e usa quello.

Con quali conseguenze per l'utente medio? E' ovvio che:
- se ipotizza un tempo di elaborazione troppo lungo,la macchina si ritroverà a disposizione meno WUs del normale (scheduler pessimista);
- se ipotizza un tempo troppo breve e scarica un bel po' di WUs, la macchina non ce la fa e va fuori deadline (scheduler ottimista e scriteriato).

Il parametro, di fondamentale importanza quindi!, è il "famoso" Result duration correction factor (RDCF).
- Il valore di riferimento è 1.
- se la macchina è efficiente, il parametro scende sotto l'1.
- se la macchina ha tempi più lenti del normale il parametro sale sopra 1.
Date un'occhiata a questo valore nelle statistiche delle vostre macchine: un valore di 0.6 o inferiore indica una macchina molto efficiente.

Ora, che succede con il nuovo scheduler? Che, a causa di bug, può capitare che se i tempi di elaborazione di un PC si abbassano, l'RDCF aumenta, invece di diminuire! Con quale conseguenza? Che ovviamente lo scheduler finirà per scaricare sempre meno WUs...

1) Meno male che la 5.8.8 era stabile e vivamente consigliata!
2) Comincio a pensare che sia una vera e propria congiura per gli amanti delle grandi cache!
3) Ovviamente stanno già testando la 5.8.9!

[GHz]

Originariamente inviato da lucab76

In realtà non hai risolto il problema!
Tra le WUs che hai buttato via e l'aumento del buffer... non hai convinto lo scheduler che potevi tranquillamente ricevere altro lavoro... gli hai semplicemente detto: "Oh, io sono senza lavoro... fai un po' te!!".

Il vero problema è fargli capire che se aumenti il work buffer richiesto, è perchè vuoi un maggior numero di WUs. Lui però ragiona al contrario! E pensa: "Vuoi un buffer più grande? Allora sei più vicino alla scadenza! Allora a te, niente lavoro!"

Sarebbe giusto, se boinc fa il conto e chiede il massimo di wu in base alla cache impostata ma in modo da elaborale tutte entro la scadenza, ma a quanto pare non è così....

I miei complimenti a chi ha sviluppato il nuovo dement-scheduler! E chissà quanto c'avranno studiato sopra!!
Unico commento:

in effetti.....luca devi fare da beta tester anche te

Originariamente inviato da lucab76

Tenete conto questo importante fatto:
- La 5.4.11 usava i giorni di cache in questo modo: hai impostato 10gg? Bene, io ti dò 10gg di lavoro per ogni progetto a cui partecipi (sempre tenendo conto dei debiti a lungo termine, del tempo di attività della macchina, delle risorse dedicate ad ogni progetto, ecc.).
- La 5.8.8 usa i giorni di cache in modo diverso: hai impostato 10gg? Bene, io ti dò 10gg di lavoro tra tutti i progetti a cui partecipi.

Quindi a parità di cache, il lavoro disponibile per ogni progetto è destinato a calare in base al numero di progetti su cui è attaccata la macchina. Se avete un solo progetto attivo, vi ritrovere "solo" a dover gestire l'assurda regola della deadline. Se invece lavorate su due progetti, avrete una cache di 5gg per entrambi; su tre progetti, cache di 3,33gg per ognuno; e via di questo passo!

Mi sembra giusto questo.....giustissimo...anzi, dovrebbe regolare le percentuali delle wu in base alle risorse dedicate a ciascun progetto (resource share) però dovrebbe tenere anche conto se un progetto è sospeso o è impostato di non richiedere nuovo lavoro, le sue risorse devono essere date agli altri, altrimenti non torna!

Originariamente inviato da lucab76

Altro bug inquietante... tanto per cambiare!

Dunque, quello schifo di scheduler, per funzionare, ha bisogno di sapere quanto ci mette un utente ad elaborare una WUs. In base a questo dato e in base a quanti secondi di lavoro sta per chiedere, si calcola il numero di nuove Wus da scaricare.

Per tenere aggiornato il tempo di elaborazione, lui ne dà una stima iniziale in base ai benchmarks, poi lo corregge alla fine dell'elaborazione di ogni WUs. Per approssimazioni successive, arriva ad un valore, si assesta e usa quello.

Con quali conseguenze per l'utente medio? E' ovvio che:
- se ipotizza un tempo di elaborazione troppo lungo,la macchina si ritroverà a disposizione meno WUs del normale (scheduler pessimista);
- se ipotizza un tempo troppo breve e scarica un bel po' di WUs, la macchina non ce la fa e va fuori deadline (scheduler ottimista e scriteriato).

Il parametro, di fondamentale importanza quindi!, è il "famoso" Result duration correction factor (RDCF).
- Il valore di riferimento è 1.
- se la macchina è efficiente, il parametro scende sotto l'1.
- se la macchina ha tempi più lenti del normale il parametro sale sopra 1.
Date un'occhiata a questo valore nelle statistiche delle vostre macchine: un valore di 0.6 o inferiore indica una macchina molto efficiente.

Mi sembra giusto Quindi questo RDCF è calcolato dal client....e lo aggiorna ad ogni wu in base tempo di elaborazione giusto? E' memorizzato nel client state?

Ora, che succede con il nuovo scheduler? Che, a causa di bug, può capitare che se i tempi di elaborazione di un PC si abbassano, l'RDCF aumenta, invece di diminuire! Con quale conseguenza? Che ovviamente lo scheduler finirà per scaricare sempre meno WUs...

Speriamo che lo correggano subito!

1) Meno male che la 5.8.8 era stabile e vivamente consigliata!
2) Comincio a pensare che sia una vera e propria congiura per gli amanti delle grandi cache!
3) Ovviamente stanno già testando la 5.8.9!

Nella ML boinc_loc, dedicata alle traduzioni, ho trovato questo messaggio di Rom che si occupa del boinc manager:

Howdy Folks,

There have been a few updates to some strings in the UI since
5.8 went public. I'll be checking in some changes tomorrow to deal with
the c-format string problems in the new UI components tomorrow. We'll
more than likely need to release 5.8 updates through the end of the
month.

Any changes you all submit will be ported to the 5.8 branch to
be included in the next 5.8.x release.

When we switch gears to work on 5.10 I'll post an announcement
here. Two weeks after the announcement I'll release one final 5.8 build
which will contain the latest localization updates. Once that final
localization build is done 5.8 will be frozen in time.

I hope this will meet with every ones expectations since a lot
of languages were not able to be updated at the last moment before 5.8.8
was released to public.

----- Rom

Quindi oltre allo scheduler saranno risolti anche alcuni bug del manager e saranno aggiunte le nuove localizzazioni, quindi dobbiamo impegnarci ad aggiornare la nostra traduzione e mandargliela Ma per questo c'è l'apposito topic

Ciao,
GHz

[lucab76]

Originariamente inviato da GHz

Sarebbe giusto, se boinc fa il conto e chiede il massimo di wu in base alla cache impostata ma in modo da elaborale tutte entro la scadenza, ma a quanto pare non è così....

No, è stitico... Io avevo pochi giorni di buffer con la vecchia versione, ho messo la nuova e gli ho chiesto nuovo lavoro a cache quasi vuota... e lui... panic mode & no new work!

Originariamente inviato da GHz

in effetti.....luca devi fare da beta tester anche te

Eh guà! Dammi anco vella lì!

Originariamente inviato da GHz

Mi sembra giusto questo.....giustissimo...anzi, dovrebbe regolare le percentuali delle wu in base alle risorse dedicate a ciascun progetto (resource share) però dovrebbe tenere anche conto se un progetto è sospeso o è impostato di non richiedere nuovo lavoro, le sue risorse devono essere date agli altri, altrimenti non torna!

Cerrrto... come no! Infatti prima con due progetti, uno sospeso, non andava oltre il 50% di cache! Invece di darmi i dieci giorni di cache era stitico anche in quel caso! Avevo messo la 5.8 proprio per vedere se risolvevano questo problema... e infatti... di male in peggio!

Originariamente inviato da GHz

Mi sembra giusto Quindi questo RDCF è calcolato dal client....e lo aggiorna ad ogni wu in base tempo di elaborazione giusto? E' memorizzato nel client state?

Giusto! E viene memorizzato sotto Project, nei tag <duration_correction_factor>0.693655</duration_correction_factor>

Originariamente inviato da GHz

Speriamo che lo correggano subito!

[lucab76]

Originariamente inviato da lucab76

Altro bug inquietante... tanto per cambiare!
[...]
Ora, che succede con il nuovo scheduler? Che, a causa di bug, può capitare che se i tempi di elaborazione di un PC si abbassano, l'RDCF aumenta, invece di diminuire! Con quale conseguenza? Che ovviamente lo scheduler finirà per scaricare sempre meno WUs...

Ho appena installato la 5.8.9 sulle mie due macchine "convertite" (ahimè) alla nuova versione di BOINC.

Il bug è stato risolto, il RDCF è tornato a scendere e la versione è stabile come la precedente. Quindi chi ha installato la 5.8.8, passi subito alla 5.8.9.

[lucab76]

Ok... adesso sono veramente

Cronaca degli ultimi giorni:
Il nostro eroe, dopo aver scaricato qualche WUs in più, diminuendo la cache dalle preferenze, ha scaccolato beato le sue WUs di SIMAP così faticosamente conquistate.
Oggi, dopo essere rimasto con poche WUs in cache, ha deciso di aprire a uFluids, settando la cache a 1.5gg. Il nostro eroe era infatti perplesso: con uFluids ancora in beta era rischioso riempirsi la cache... se fosse incappato in una mandata storta avrebbe dovuto abortire una camionata di WUs.
Così, bello bello, cacchio cacchio, il caro scheduler inizia a scaricare... prima 5, poi 6 WUs, poi si ferma...

Il nostro eroe era contento: "beh" - s'è detto - "visto quello che ha fatto con 7 giorni, è normale che si fermi dopo 11WUs con 1.5gg di cache". Chiuso BOINC se n'è andato in palestra e a cena dalla dama...

Ma, OHIBO' , al suo ritorno... che succede? Apre BOINC e... si accorge che l'amato scheduler ha scaricato per lui 360 WUs da 2 ore l'una...

SCUSATE... MA QUANTO KZ RICHIEDONO 360WU DA DUE ORE?
720 ORE, OVVERO 30 GIORNI.
MA SE GLI HO CHIESTO 1 GIORNO E MEZZO DI CACHE!!

Ora mi spiegate come faccio a farle tutte prima del 22 (deadline)? Lo scheduler, come ha potuto pensare che ci potessi riuscire?

Quando accadono queste cose mi sfavo come una iena! Shrek boia! Ma è possibile? Come devo impostarlo questo BOINC del cavolo?
E il bello è che lui è lì, mi guarda, dal basso della sua iconcina blue e...

Ho postato anche sul forum di BOINC. Vediamo cosa mi rispondono!

[Il Capitano]

Hai il mio appoggoi per l'inevitabile perdita di quelle WU, pero' te lo devo dire, mi sembri un po' fantozzi