Invece che sulla sospensione, proverei a giocare di firewall, con il trucchetto di Morse.
Consentire l'invio ma non il report bloccando la porta e/o l'IP.
Cerco di riassumere a memoria che è tutto perso nei meandri del thread RLM.
Rosetta, quando finisce l'elaborazione, invia i dati allo stesso IP da cui prende le WU.
Ma l'ultimo passo, il report appunto che conclude tutto e da' l'ok per la validazione, lo fa su un IP diverso che aveva trovato Morse osservando il traffico sul suo router.
Bloccato quello era possibile completare le WU, tenere aperta la rete a BOINC, scaricare nuove WU giocando con ncpus nel cc_config e tenere pulito l'HD perché non serviva sospendere.
Poi all'inizo del challenge semplicemente si sblocca l'IP.
BOINC riesce a fare il report e la validazione di tutte le WU già consegnate spara i crediti in classifica.
La quadratura del cerchio praticamente
Premesso che bisogna vedere come stanno le cose con POGS, perché il giochino funziona come detto solo se ci sono 2 IP diversi, ecco come procederei io.
Scenario: il mio I7 HT, quindi BOINC vede 8 core e supponiamo (da verificare) che la deadline su POGS sia di 10 giorni anche qua.
Se imposto boinc per 10+10 giorni di scorta lui si organizza secondo gli 8 core che conosce.
Ma 10 giorni prima (deadline) modifico il cc_config.xml e modifico (o metto) il tag "ncpus" invece che a -1 a 32.
"-1" dice a BOINC di fare i conti con i core che vede. Ma se metto un numero >=0 gli dico QUANTI CORE DEVE CONSIDERARE.
Quindi con 32 lui si organizza per 32 core e prende lavoro per 32 core per 10+10 giorni.
Perché 32?
Perché credo anche POGS abbia un limite max di WU per core invalicabile, indipendentemente dalla scorta che decidiamo (DA VERIFICARE).
Fatta la scorta massima si riporta a -1 il "ncpus" in modo che BOINC lavori tranquillo con i core disponibili e non faccia casino cercando di aprire 32 wu
A questo punto si chiude l'IP su cui fa report POGS e si lascia BOINC a lavorare tranquillo.
Lui finisce, manda i dati ma la WU rimane in "Pronto per il Report".
Il bello è che se le WU prese le finiamo prima dell''inizio (limite max per core, v. sopra), dovrebbe bastare reimpostare di nuovo il ncpus (p. es. a 48) e si prende qualche altra WU di straforo.
Il giochino a questo punto è chiaro.
Qualche ora dopo l'inizio del challenge (io di solito faccio la mattina, non appena inizia) si riapre l'IP e si consente il report.
La figata sta nel fatto che se tutto funziona secondo questo scenario, dopo aver reportato e presi i primi crediti, si scaricano NUOVE WU e si comincia a calcolare quelle. SENZA PERDERE TEMPO A COMPLETARE LE WU SOSPESE
Che ve ne pare?
Ci sono solo 3 cose da vedere:
1- la deadline
2- l'IP del REPORT, sperando che sia diverso
3- l'ammontare dell'eventuale liimite max di WU per core
Se la 2 non è vera (stesso IP) io metto ncpus a 64 e spero che siano sovrabbondanti.
Se non dovessi finirle tutte prima dell'inizio, e sono in zona deadline, le annullo e ne prendo altre.
Ricordiamo che un progetto BOINC non viene in nessun modo danneggiato se si annullano delle WU o non si finscono entro la DL, il sistema è fatto in modo da superare l'evento e la WU viene semplicemente riassegnata ad altri come se fosse la prima assegnazione.
Commenti, suggerimenti, aiuto per le verifiche sopra sono graditi.
Bye, R!
p.s.
Le stats sono già pronte per il CHL, devo solo attivare il fetch un paio d'ore prima.