ARGOMENTO:

Hanno la mia più totale comprensione.
Sono ormai due anni che anche la nostra piattaforma su cui si appoggia BoincItaly è sommersa da schifezze con injections di codice cacca nei files , cosa che viene rattoppata quotidianamente ... si necessita di un upgrade della piattaforma anche per stare al passo con i tempi ma qui ora si và ben oltre alle competenze (seppur limitate) volontarie.

Per quanto rigurada B.I. c'è il bisogno del supporto dell'intera comunità altrimenti non so per quanto potremo resistere

Sembra che alla fine abbiano fatto passare la "legge"...
Stiamo a vedere come si evolverà la cosa

Gli amministratori del progetto hanno rilasciato una nuova versione dell'applicativo Nbody, la 1.68, che aggiunge nuovi parametri per la ricerca che stanno conducendo sulla dispersione di velocità

boboviz ha scritto:

Gli amministratori del progetto hanno rilasciato una nuova versione dell'applicativo Nbody, la 1.68, che aggiunge nuovi parametri per la ricerca che stanno conducendo sulla dispersione di velocità

comunque prediligono sviluppare per MultiThread che single thread, per queste applicazioni per cpu..

Volendo si possono eseguire single thread con un app_config.xml apposito.

Nubman ha scritto:

Volendo si possono eseguire single thread con un app_config.xml apposito.

a dire il vero, sulle applicazioni ci sono sia quelle semplici che le mt per windows e per linux, ma la disparità di gflops messi a disposizione è evidente.
Si tende a puntare sul cavallo vincente, ok, ma a conti fatti, è una forzatura per preferire i mt.

Il loro sito dovrebbe avere qualche problema, non si carica...

Da quello che ho capito, per ovviare ai problemi di sovraccarico volevano procedere con l'upgrade di ram e cpu.
Ma mentre erano "indietro a fare" qualche cosa non è andata per il verso giusto.
Comunque un minuto fa il sito era raggiungibile.

E intanto hanno rilasciato il nuovo applicativo Nbody (versione 1.70)

Dopo secoli ho completato la scheda progetto di Milky (aggiungendo la sezione "informazioni scientifiche")....uff, che fatica.

ciao ragazzi, sto testando questo progetto sulla gtx 750ti. 1 wy manda la gpu al 95-100% e utilizza il 20-30% della ram.
Ha senso elaborare 2 wu contemporaneamente? o semplicemente raddoppierei i tempi di comletamento e aumentare le temperature?

Per quanto riguarda la cpu ho visto che hanno una app multithread (che devo ancora provare)
E' possibile stabilire il numero di thread per ogni wu? ad esempio impostando 1wu con 4 thread, oppure 2wu con 2 thread ciascuno?
Tra le preferenze del progetto non vedo tale opzione. Bisogna farlo con app_config?

Le schede verdi non sono proprio il megli per Milky Way.....è fatto per le ATI.

Buro87 ha scritto:

ciao ragazzi, sto testando questo progetto sulla gtx 750ti. 1 wy manda la gpu al 95-100% e utilizza il 20-30% della ram.
Ha senso elaborare 2 wu contemporaneamente? o semplicemente raddoppierei i tempi di comletamento e aumentare le temperature?

Sicuramente aumenterai il rac, anche se non so dirti di quanto.
La temperatura non dovrebbe aumentare di molto, visto che sei quasi a pieno regime.
Di solito il limite è l'usabilità dell'interfaccia grafica, nel senso che se il computer viene usato anche come desktop i ritardi o i blocchi momentanei delle finestre sono fastidiosi.

io direi che se l'utilizzo della gpu è su 95-100 % con una sola WU, non ha senso mettere 2 wu in contemporanea, si raddoppiano i tempi di elaborazione.

e in genere solo se l'utilizzo è tra il 50 e il 100% può aver senso.
per quanto riguarda le mt l'unico modo direi sia quello di utilizzare client multipli, settando il numero di cpu per ogni client

Si possono limitare le wu mt con app_config.xml. Così per 4 thread:

Il parametro <cmdline> non è sempre necessario ma in alcuni casi è meglio metterlo in accordo con <avg_ncpus>

C'è qualcuno che sta scaccolando su MIlky con gpu ???

Ho riscontrato un nuovo comportamento che mi sembra un po eccessivo (mi sembra di ricordare solo da qualche settimana)
Le Wu di sola GPU, sono distribuite una sola per volta.
Per spiegarmi meglio: vengono distribuite se, e solo se, nel pc non c'è alcuna WU di gpu, di qualsiasi progetto.
E inoltre, mentre prima almeno la prima volta te ne scaricava circa 40 (anche se è un valore ridicolo per le schede di oggigiorno), adesso te ne scarica solo 1

Ho provato a cercare sul loro sito se c'è stata una dichiarazione su questa nuova modalità, ma non ho trovato nulla.
E' solo una situazione mia, o anche altri hanno riscontrato questo ?

sui 4 pc che ci lavorano la coda e` abbastanza piena (direi come al solito), vedi qui: milkyway.cs.rpi.edu/milkyway/hosts_user.php?userid=58935

Grazie, ho visto.

L'unica differenza è che hai schede ATI e per ora ho provato con la NVIdia 1080.

Qando avrà finito la sua coda, proverò sull'unica ATI che ho. (le due schede lavorano su client differenti e quindi su progetti differenti)

Mi hanno risposto sul sito.
E' stata una mia "c.....a"
Se si mette a zero la percentuale di risorse assegnate al progetto, il comportamento è proprio quello che ho riscontrato (solo una WU per volta e, se non esistono altre WU in coda)

Micromanaging CPU vs GPU Workunit Limits
Hey Everyone,

I will be tweaking some config options on the server to better improve database stability and allow for stockpiling of more workunits by GPU users.

The new workunit limits should be as follows:
Separation:
600 total
200 GPU (Per GPU up to 600)
40 CPU (Per CPU up to 600)
Nbody:
120 total
20 CPU (Per CPU up to 120)


Hopefully you guys notice this on your end. If we notice we are running out of workunits more frequently on the server, I will increase the workunit cache a bit.

Let me know what you all think about these numbers and how it is working for you.

Jake 17 Jan 2019, 21:56:52 UTC

Finalmente qualche progetto incomincia a rivedere la politica di distribuizione delle WU.

Adesso tocca a SETI (100 WU sono veramente poche con le cpu e soprattuto con le GPU che ci sono adesso)