ARGOMENTO:

Nubman ha scritto:

Per chi volesse fare scorta con i client multipli (viste le parecchie ore che intercorrono tra i vari batch di workunits) vi informo che, se è aperto più di un client multiplo insieme al client principale e si volesse elaborare con il client multiplo, c'è qualcosa di impalla nella vm (non trova proprio marius/lsplitsims ecc...) senza un motivo apparente. Chiusi tutti i client (compreso quello principale) tranne quello interessato il lavoro sembra riprendere senza problemi, ergo la mia conclusione è di evitare la sovrapposizione di client durante lo scaccolo.

Occhio che se ognuno facesse una megascorta nel finale (fino a 7gg) potremmo accaparrarci virtualmente non si sa quante centinaia di migliaia di crediti. Nel caso servisse...


Altra cosa che ho notato. Ogni batch è di circa 100k workunits, quindi il 10% di tutta la fase di testing. Ultimamente ogni batch dura 5 giorni e quello attualmente rilasciato è uno degli ultimi 4. Dovremmo terminare entro 20gg di questo passo. Sempre al passo attuale potremmo diventare primi in circa 7gg.

BILD e client multipli running fine ...

ma ho notato che ci mette il doppio del tempo se non di più (ovviamente..) , consegnando circa 3 WU (1 per client) , ho notato che ne consegno dalle 3 alle 5 WU nella stessa unità di tempo elaborativa (minuto più minuto meno) eseguendo il client normalmente...

sabayonino ha scritto:

BILD e client multipli running fine ...

ma ho notato che ci mette il doppio del tempo se non di più (ovviamente..) , consegnando circa 3 WU (1 per client) , ho notato che ne consegno dalle 3 alle 5 WU nella stessa unità di tempo elaborativa (minuto più minuto meno) eseguendo il client normalmente...

In questo caso i client multipli servono per accumulare più di 40 wu per pc, non per eseguire più di 1 wu contemporaneamente. Suggerisco questo metodo perché modificando il parametro ncpus da file di configurazione si ottiene sì più lavoro, ma lavoro che gira soltanto se poi mantieni quel numero di ncpus. Es. Se hai 8 thread e metti 32 ncpus, ti scarica delle wu per processori da 32 thread. Tornando a ncpus=8 poi, non lavora su queste wu.

questa è la tabella dei risultati che ho elaborato

per cui sembrerebbe che usare, in questo progetto/applicazione, il multithreading (MT) sia poco efficiente.

in altre parole sembrerebbe essere molto meglio far girare solo clienti multipli, ciascuno con un solo core assegnato.

A sensazione, nei giorni scorsi, mi era infatti sembrato che a variazione nel numero di cores assegnati non corrispondesse uguale variazione dell'elapsed time.
A pensarci bene lo si può anche spiegare in parte con il fatto che, molto probabilmente, il programma fa girare in MT solo alcune parti della procedura, e quindi rimane una parte "fissa" che non viene ridotta dall'utilizzo della tecnica MT.

Adesso provo, piano, piano, a terminare i clients con ncores>1 e a trasformarli in clients con ncores=1.
Discorso su cui forse si dovrà fare attenzione sarà sull'utilizzo della RAM

Sto provando solo adesso ma mi sembra che funzioni bene. Si può dire quanti thread usare con l'app_config.
avg_ncpus dice a boinc quanti core riservare per la wu
Con cmdline si passa al wrapper il numero di thread da utilizzare

Così eseguo due wu in simultanea, mettendo 1 in entrambi i parametri dovrebbe farne una per core

@ratto

molto interessante questa soluzione.

Nel mio cosa che ho una cpu a 16cores virtuali

dovrei fare
e quindi dovrei trovarmi 16 wu in contenporanea, giusto ???

se così è mi semplifica di molto il passaggio a un core per WU

zioriga ha scritto:

@ratto


e quindi dovrei trovarmi 16 wu in contenporanea, giusto ???

Si se la matematica funziona come penso io

con questa tecnica si può anche pensare di fare una mega scorta, giocando sul parametro ncpus del file cc_config,xml

sono infatti riuscito a farmi una scorta di 160 WU portando da 16 a 32 il parametro ncpus (tecnica da utilizzare nei momenti opportuni)

Ok, proverò l'app_config di rattorosso.

Zio, cosa dice alle risorse in uso se clicchi il pulsante Proprietà delle wu che hai scaricato dopo aver aumentato ncpus? Riporta sempre 1 solo core?

Edit: potreste riportare qualche tempo delle vostre wu? A me se superano i 40 minuti vanno peggio del mt.
Edit2: ok, la prima wu è terminata in 27 minuti. Se ci mettono tutte lo stesso tempo, registrerò un bel miglioramento pure io. In tal caso potrei pensare di fare la stessa configurazione per il notebook.
Edit3: al momento (dopo 9 wu completate) il tempo medio è 42 minuti e tra l'altro c'è una wu in corso da 1h15m. In ogni caso anche con il mt ci sono wu sporadiche che durano da sole più di 20 minuti (ovvero anche 160 minuti se moltiplichiamo per 8). Inoltre, 10-12 wu all'ora è la massima stima per il mt sul mio processore, ma in generale 7 wu all'ora dovrebbe essere un valore ragionevole. Quindi, diciamo che fin quando completo 8 wu mediamente in meno di un'ora posso stare tranquillo che il risultato è maggiore o uguale a quello ottenuto con il mt.

attenzione che potrebbe anche essere un problema di allocazione di RAm per ogni client.

controlla quanta RAM è assegnata a ogni client

mi è successa una cosa molto strana:

avevo creato l'app_config ed ero riuscito a scaricare 160 WU e sembravano tutte ok (le avevo fatte girare per pochissimi secondi e poi avevo sospeso il progetto.

quando si è trattato di incominciare a mandare avanti l'elaborazione, mi sono trovato che tutte le WU si erano trasformate in Wu da 8 cores, in poche parole avevo perso tutto il lavaro fatto (una WU = 1 core)

ho provveduto a cancellare tutto e ripartire con un core , vedremo cosa succederà quando dovrò passare a 2 e più cores

zioriga ha scritto:

attenzione che potrebbe anche essere un problema di allocazione di RAm per ogni client.

controlla quanta RAM è assegnata a ogni client

Ho 24GB, non credo che ci possano essere problemi.

Intanto ho ricalcolato la media... ho 8,3 wu/h per le ultime 40 wu. Non è che sia tutto questo granché, considerando che ora il lavoro è pure più frammentato e non posso più chiudere i client senza lasciare almeno 7 wu interrotte. Qualcuno riscontra benefici invece?

Non saprei, non ho calcolato i tempi. In generale non vedo molto bene le wu mt in boinc visto che il lavoro è già multithreaddato a monte, ma forse il fatto di avere tante vm in esecuzione pesa. Chissà perché hanno scelto di farle così

Ho una wu a 6h29m e al 19.4%. E ora che faccio?
Di solito quelle che durano ~3h sono già al 100%.


Edit: l'ho sospesa quando è arrivata a ~7h, me la tengo nel caso trovi occasione per scaccolarla. O qualcosa è andato storto nella vm o il suo thread ha avuto poco spazio nelle risorse e quindi molte pause. Ad ogni modo è anche vero che potrei abortirla dato che in 7 ore a voglia a completare wu più corte!

Sto invece pensando al fatto che con 1 solo client configurato con questo app_config (1 thread per wu) dovrebbe essere sufficiente per fare un'unica scorta. Con la configurazione di default avrei dovuto usare 42 client per arrivare a 7gg di scorta. Non che sarebbe stato assurdo gestirli dato che ho uno script che li completa in maniera incrementale, però, se si può evitare la soluzione più complessa, è meglio. Quindi, è possibile che non torno al mt.


Questo è uno screenshot della situazione attuale: postimg.org/image/hwstwv2x7/

La wu da 4 ore verrà completata prima o poi; da notare che, differentemente da quella che ho dovuto sospendere, questa è al 100%. Potrebbe essere una strategia ragionevole abortire tutte le wu che superano 2 ore a prescindere, ma forse sarebbe cherry picking e da onesto scaccolatore non vorrei "violare boinc". Da notare che, anche se fosse cheating, il BOINC Credit System non potrebbe farci nulla perché il credito è fisso (normalmente la punzione sarebbe una riduzione progressiva del credito assegnato).

Piccolo aggiornamento sulle wu lunghe che avevo in coda...

La wu di 7h ore è stata reportata dopo che l'ho sospesa con l'opzione di non lasciare le app sospese in memoria. Mi ero accorto che la vm era in uno stato di pseudo-spegnimento, quindi è bastato farla ripartire in qualche modo o riavviarla. Evidentemente aveva finito, ma teneva occupata una 'piazza' su BOINC facendomi scaccolare 7 wu invece di 8 alla volta.

La wu invece che sembrava terminare (dato che era al 100% e ne ho viste parecchie comportarsi così) l'ho abortita dopo 5h pensando di aver superato il tempo limite da un pezzo. Ho trovato questo grafico sul forum di Cosmology:

Il post è questo: www.cosmologyathome....um_thread.php?id=7365&postid=20902#20902
In pratica quella sarebbe la distribuzione degli step all'interno di ogni wu, per questo motivo la maggior parte delle wu sono veloci, ma ce ne sono anche altre che prendono una marea di tempo. Ovviamente la barra di completamento non funziona correttamente per queste ultime e l'admin Marius vorrebbe fare un fixare questa cosa.

Assumendo che una wu di quelle veloci abbiano 250 nfev e durino 27 minuti (usando 1 solo thread) vuol dire che a quella wu che avevo in corso ne avrei dovuto dare al max 270 di minuti, cioè 4.5 ore. Supponendo invece che siano quelle da 40 minuti le più corte, allora il tempo limite potrebbe essere più alto, circa 6.5h. Boooooh!

Sinceramente... ho altre cose di cui preoccuparmi.

Parte di questo messaggio è nascosta ai visitatori. Prego registrarsi e/o effettuare l'accesso per vederla.


configurati 20+1

vedo che anche tu Saba ti stai "ubriacando" di client multipli

Un giorno devo provare assolutamente provare BILD.


Parte di questo messaggio è nascosta ai visitatori. Prego registrarsi e/o effettuare l'accesso per vederla.

Non riesco ancora a capire perché sui nuovi client le wu non partono come dovrebbero.
La prima wu rimane in uno stato di loop infinito allo 0,1%... poi se chiudo i restanti client, sembra non cambi nulla.
Abortisco 2-3 wu perché mi ricordavo che sull'altro host aveva funzionato, ma anche no.
Faccio update del progetto per reportare le wu annullate (che erano il loop, appunto).
Riavvio il client incriminato (che è pure l'unico rimasto aperto) e dopo un po' parte lo scaccolo.
Cosa c'è di normale in questo?

Già so che dovrò bestemmiare pure al prossimo cambio client.

nel frattempo faccio scorticciole ....
ho riacceso un pc ... faccio un pò di powersafe
domani seguirà l'altro ...faccio il boot dell'ISO di BILD da HDD così me la gestisco meglio...

dalla prossima rilevazione delle 9.00, la mia rilevazione www.wmtools.it/zioriga/PlankSimsStatsPrevisioni.htm sarà fatta calcolando la velocità in base alle 12 ore precedenti e non più nelle 24 ore.
il motivo di questo è per seguire e valutare meglio le fasi di rallentamento dovute ai periodi di scarseggiamento di WU e alle fasi di riavvio dopo la nuova generazione di WU.
La fase centrale di piena disponibilità dovrebbe presentare un andamento pressochè costante delle rilevazioni (salvo ovviamente le piccole oscillazioni dovute principalmente alla diversa frequenza con cui Cosmology produce i dati, che sembrano essere aggiornate con un intervallo un po superiore a un ora)