ARGOMENTO:

astroale ha scritto:

Ho letto in chat che qualcuno vuol provare a mettere f6 da cmdline ... se lo fa può essere così gentile da controllare il consumo di CPU dell'explorer.exe ?
Giusto per confrontare il comportamento con il problema che rilevavo io e di cui parlavo qui . Grazie!

io ho messo "f6" da qualche giorno:
BOINC 6.10.24, WinVISTA 64bit, i7 965, 3GB RAM, ATI 5970 tutto stock

avevo iniziato a mettere f10 ma non cambiava nulla, poi f8 e ancora nulla. Poi f6 e qualcosa è cambiato ma sto facendo esperimenti

Riguardo explorer.exe: 8 secondi di runtime totale in 4 ore di esercizio

Il parametro f su Milkyway, come l'ho capito io.

PC con processore i7 965 - HD5970 - PCIe2

impostazione standard (f30)pacchetti inviati alla GPU con frequenza 30Hz
dopo la fine di ogni pacchetto libera la GPU
quindi si permette alla GPU 1000/f = 33.333 millisecondi di lavoro
runtime previsto puro = 640 x 138 = 88.5 secondi
se il runtime previsto per una iterazione è 138ms dovrà essere suddiviso in pacchetti (138/33.333 = 4,14 approssimato per eccesso 5)
per ogni iterazione alla GPU vengono inviati 5 pacchetti con del tempo morto nel mezzo
lavorando a f30 ottengo una WU completa in 105 secondi

impostazione modificata (f2)pacchetti inviati alla GPU con frequenza 2Hz
quindi si permette alla GPU 1000/f = 500 millisecondi di lavoro
l'iterazione non viene suddivisa in pacchetti ma fatta tutta in una volta (durante la quale la GPU è inservibile)
lavorando a f2 ottengo una WU completa in 94 secondi

ottengo lo stesso risultato con f6 (f7 è al limite) perchè gli faccio fare una iterazione di calcolo in un colpo solo


In pratica per ottimizzare la velocità di elaborazione bisogna vedere nei report delle WU standard di Milkyway (perchè ce ne sono anche di durata inferiore) quale sia il tempo previsto per una iterazione e calcolare "f" in modo da permetterglielo in un colpo solo o in meno "passate" possibili in funzione dell'uso che uno fa del suo PC (grafica, editing, di giorno, di notte).
Forse anche 2 app_info.xml andrebbero bene, uno per quando si usa il PC, uno per quando lo si lascia scaccolare



Ho provato a le stesse cose sul secondo PC
PC con processore Q6600 - HD5970 - PCIe
non ottenendo assolutamente i risultati sperati
il PC è in controllo remoto quindi questo può aver creato disturbo.

man mano che calavo "f" diminuivano le segmentazioni da dare in pasto alla GPU correttamente
ma ho notato una giusta diminuzione del tempo CPU e stranamente un aumento deciso del tempo GPU
f30 --> tempo GPU 103 secondi
f2 --> tempo GPU 150 secondi

forse con il controllo remoto impasto il driver grafico, o forse è il sistema operativo a 32bit (ma non credo)

E' un problema che non si pone, a giorni toglierò la scheda dal Q6600 e la piazzerò sul secondo i7. Esperimento interessante comunque.

Ho fatto molte prove pure io con questo sistema:
Q6600@3,6 ghz
HD4870
HD4850
Seven 64 bit

Ho provato molti parametri ed alla fine ho messo f5 come miglior compromesso e 2 WU simultanee per ogni scheda.
Gli altri parametri w, p, e b possono influenzare molto i tempi di elaborazione.
Se diminuisco w calano i tempi ma sotto ad una certa soglia aumenta troppo il tempo cpu senza benefici.
Con b-1 calano moltissimo i tempi per ogni WU ma aumentano a dismisura i tempi cpu.

Sono anche certo che ogni scheda video vuole i suoi parametri per rendere al meglio quinid questi valori sono da predere come relativi e non come assoluti.

Comunque ottimizzando il tutto otterrei 205.000 crediti giornalieri dai precedenti 185.000 circa.


Altra cosa.
In questi ultimi giorni arrivano Wu di lunghezze molto minori e il lavoro non è abbastanza per le 2 schede.
Ho risolto mettendo pure collatz in elaborazione con dividendo la percentuale delle schede in modo che appena manca il lavoro a MW parte collatz senza, per questo, andare ad intaccare i tempi di elaborazione.

Da qualche giorno è stata rilasciata l'applicazione ufficiale per windows 64 bit. La scarica automaticamente senza dover usare l'app_info

più che altro, solo da stanotte sono finalmente riusciti ad aggiornare tutto il boinc server e a permettere la gestione ati in automatico.

volevo mettere la news ma c'è un problema: il nuovo server (ora aggiornato come quello di aqua e come sarà presto anche quello di collatz - bloccato solo perché giustamente non voleva smanettare mentre anche l'unico altro progetto ati stava avendo problemi) gestisce le news come thread del forum, quindi i link non funzionano più. Come si fa? Non si mette più il link alla news originale?

ps: con l'aggiornamento, hanno anche cancellato tutto il vecchio archivio news, quindi tutti i link che abbiamo sono andati persi.

Linka da dentro il feed RSS

milkyway.cs.rpi.edu/milkyway/rss_main.php

Passi sulla news e copi li link, poi ti manderà al thread sul forum, AMEN. Mi sembra la soluzione meno peggio

eh ma il fatto è che il codice php è fatto per riportare il # della news, non il # del thread. Il link non funziona più se metto il # del thread perché il software del nostro sito ricompone un indirizzo sbagliato (vedo che le ultime news fatte per aqua ad esempio non hanno i link alla news originale, chi le ha fatte ha lasciato il link generico all'homepage).
Quello che sollevavo è un problema che diventerà esteso a tutti i progetti quando aggiorneranno il software del loro server. Penso che basti poco comunque per correggere il codice php per permettere anche di linkare il # di un thread...

cenit ha scritto:

...
Quello che sollevavo è un problema che diventerà esteso a tutti i progetti quando aggiorneranno il software del loro server. Penso che basti poco comunque per correggere il codice php per permettere anche di linkare il # di un thread...

si, lo avevo notato anche per altri progetti

nel giro di poco correggo il codice linkando la pagina giusta del forum... purtroppo perdiamo i link alle news vecchie ma ho idea che li hanno persi pure loro

baxnimis ha scritto:

nel giro di poco correggo il codice linkando la pagina giusta del forum... purtroppo perdiamo i link alle news vecchie ma ho idea che li hanno persi pure loro

si ma non stare a impazzire, non ne vale la pena..
il link alla news originale era una cosa "in più", se manca viviamo lo stesso

baxnimis ha scritto:

cenit ha scritto:

...
Quello che sollevavo è un problema che diventerà esteso a tutti i progetti quando aggiorneranno il software del loro server. Penso che basti poco comunque per correggere il codice php per permettere anche di linkare il # di un thread...

si, lo avevo notato anche per altri progetti

nel giro di poco correggo il codice linkando la pagina giusta del forum... purtroppo perdiamo i link alle news vecchie ma ho idea che li hanno persi pure loro

quando aggiornano al nuovo server che mette le news nel database del forum e non in quello dedicato, mi sembra che tutti i progetti perdano le vecchie news! Quindi non è un problema!

Salve a tutti

Finalmente boinc mi ha scaricato GPU sia a 32 che a 64 bit su ATI.

In entrambi i casi non riesco a risolvere una cosa: sempre e solo 24 unita' di elaborazione in coda. Cosi' se non si lascia sempre online il pc finiscono presto...
C'e' un modo per mettere la coda a 1 giorno come facevo con Collatz?

Io ho una ATI 4850, sono riuscito a fare un overclock del core fino a 750 (da 625 originale) portando le elaborazioni da 230sec circa a 190sec! Sarei interessato a provare quei parametri descritti sopra, f5 f6 ecc., dove si impostano?

A presto e grazie

Se usi l'applicazione standard, cioè è Boinc che ti ha scaricato le applicazioni, allora non puoi modificare nessun parametro.

Se invece vuoi usare le applicazioni ottimizzate allora puoi andare qui
www.arkayn.us/milkyway/index.html
e scaricare la versione a te necessaria.
Nel readme che troverai c'è scritto come impostare i vari parametri.

Per farlo devi abilitare la visione dei file e cartelle nascoste, copiare i file scaricati (sono 3: app_info + brook.dll + "applicazione.exe") dentro la cartella del progetto milkyway (che varia quesi per ogni sistema operativo), riavviare Boinc e via.


P.S. scusa per i pochi dettagli ma sono a lavoro e non ho molto tempo....

Digital Thunder ha scritto:

In entrambi i casi non riesco a risolvere una cosa: sempre e solo 24 unita' di elaborazione in coda. Cosi' se non si lascia sempre online il pc finiscono presto...
C'e' un modo per mettere la coda a 1 giorno come facevo con Collatz?

ciao!
questo è un problema non risolvibile: Milkyway lascia infatti scaricare SOLO fino a 6 WU per ciascun core della CPU del tuo pc (cosa effettivamente priva di senso quando l'elaborazione è affidata alla GPU).

La loro giustificazione è dovuta al fatto che ciascuna WU viene generata a partire dai risultati delle precedenti, per cui non riuscirebbero a generarne molte se tu potessi tenerne tante accumulate sul tuo pc. Purtroppo questo è un prezzo da pagare per ricerche di questo tipo (anche Folding@Home lavora su un principio molto simile e lì non ne puoi proprio avere in coda - ma almeno durano di più!)


edit: per poter impostare i parametri, invece, devi fare l'installazione manuale dell'applicazione come ti ha detto canapa.

PROBLEMA (risolto): "non scaricava piu' WU dal server"

Due righe giusto per tener traccia del problema, dopo innumerevoli prove e messaggi sul loro forum senza risolvere, ho trovato la mossa giusta, ho cancellato i seguenti file dalla dir dei dati:

sched_reply_milkyway.cs.rpi.edu_milkyway.xml
sched_request_milkyway.cs.rpi.edu_milkyway.xml
statistics_milkyway.cs.rpi.edu_milkyway.xml

fermato e fatto ripartire BOINC e mi ha immediatamente scaricato le fatidiche 24 WU.

Ricordo sempre per la cronoca che non avevano funzionato nell'ordine (piu o meno) i seguenti tentativi:

- reset del progretto

- modifica dei parametri della dimensione della cache
1) Computer is connected to the Internet about every n days
con n da x a 0 e da 0 a x
poi stessa cosa per il parametro:
Maintain enough work for an additional

- passaggio dall'app_info all'applicazione standard del server e viceversa

- detach e ri-attach del progetto

e altri tentativi assortiti che trovate al link del forum sopra.

Non avevo ancora provato a disinstallare BOINC e cancellare tutto perche non volevo perdere il lavoro in corso lato CPU.

EDIT
Unica cosa strana, ho dovuto mettere in pausa il Collatz per far incominciare l'elaborazione delle WU del MW nonostante queste abbiano una deadline molto piu' breve e infatti in passato partivano sempre senza stoppare a mano il Collatz ... mah

Ora che sono finalmente riuscito a farlo ripartire potrò di nuovo fare qualche prova. Ti ringrazio per i report delle tue prove e vado subito con le domande ...

baxnimis ha scritto:

impostazione standard (f30)

main integral, 640 iterations
predicted runtime per iteration is 138 ms (33.3333 ms are allowed),
dividing each iteration in 5 parts

Come fai a leggere queste informazioni ?

il PC è in controllo remoto quindi questo può aver creato disturbo.

Intendi dire con logmein ?
Purtroppo lo sto usando anche io ...

Ora stò provando a lanciare una WU per volta, perchè ho notato che al restart di BOINC i tempi delle WU sono piuttosto bassi, poi dopo poche ore si alzano e questo effetto ( forse dovuto alla frammentazione della RAM video ? ) sembra peggiorare con 2 WU assieme.
Proverò ad osservare il totale per BOINCstats qualche giorno, perchè sembra difficile fare valutazioni precise con le WU così corte che i report (per WU) spariscono velocemente anche su sito.

canapa ha scritto:

Ho fatto molte prove pure io con questo sistema:

Ti ringrazio per il report, proverò a fare un poco di prove anche io con gli altri parametri, il mio scopo però non è ridurre il CPU time che in questo momento e zero, ma l'utilizzo della CPU da parte dell'exploer.exe
Infatti ho notato che era circa il 5% (20% di un singolo core) con MW a f6 e 2 WU, mentre con il Collatz cala a meno dell'1% e mi sembra che col MW con una WU si riduca al 2%

Altra cosa.
In questi ultimi giorni arrivano Wu di lunghezze molto minori e il lavoro non è abbastanza per le 2 schede.
Ho risolto mettendo pure collatz in elaborazione con dividendo la percentuale delle schede in modo che appena manca il lavoro a MW parte collatz senza, per questo, andare ad intaccare i tempi di elaborazione.

Forse è questo che ha scatenato il problema (capitato anche a me) di mancanza di WU solo sui nostri PC, che anche se risolto in modo diverso potrebbe avere la stesa origine, cioè il Collatz (attivo) inizia a consumare sempre più GPU finchè la configurazione gli borderline di MW crede che non ci sia abbastanza GPU time per finire entro la deadline e non manda più WU.

Se è così è un problema nel senso che non si può lasciare il Collatz attivo per backappare i relativamente frequenti stop del server MW, senza rischiare di incastrare la cache MW.

Infatti in questo momento ho dovuto mettere il Collatz in suspend.

Voi in che stato lasciate il Collatz sui PC con il MW attivo ?

In genere lo lascio attivo ma dopo alcuni giorni elabora collatz quindi devo sospendere quest'ultimo.

Altra condizione che ho individuato proprio ora che potrebbe scatenare il problema cache bloccata a zero:

MW stava regolarmente reportando ogni singolo result uppato scaricando la WU successiva quando è fallito un report con questo messaggio:

Message from server: Project is temporarily shut down for maintenance

e ha smesso di reportare ogni singolo result con la coda che si stava rapidamente svuotando ... mah

astroale ha scritto:

Altra condizione che ho individuato proprio ora che potrebbe scatenare il problema cache bloccata a zero:

MW stava regolarmente reportando ogni singolo result uppato scaricando la WU successiva quando è fallito un report con questo messaggio:

Message from server: Project is temporarily shut down for maintenance

e ha smesso di reportare ogni singolo result con la coda che si stava rapidamente svuotando ... mah

io per evitare questi scherzetti di MW mantengo quella vecchia procedura di forzatura dell'aggiornamento del progetto tramite script (ora impostata su valori più blandi, ogni 3 minuti)

P.S. elaboro solo MW (nel senso che Collatz mi rimane solo come progetto di scorta sempre "sospeso" ) altrimenti ho visto che dopo un po' prende il sopravvento

baxnimis ha scritto:

impostazione standard (f30)

main integral, 640 iterations
predicted runtime per iteration is 138 ms (33.3333 ms are allowed),
dividing each iteration in 5 parts

Come fai a leggere queste informazioni ?

Sul log delle WU sul mio account di MW. Forse che con le applicazioni scaricate direttamente dal server queste info non vengano più date? Io uso ancora le ottimizzate con l'app_info

il PC è in controllo remoto quindi questo può aver creato disturbo.

Intendi dire con logmein ?
Purtroppo lo sto usando anche io ...

SI, uso logmein
A posteriori sono andato a vedere i tempi fatti da quel PC quando non era in controllo remoto: sono gli stessi. Quello che cioè temevo, che l'uso anomalo della rete e del video in controllo remoto potessero intaccare le modalità di elaborazione, non credo sia vero

Mi è venuta in mente una cosa per l'explorer. Può essere che procedure di indicizzazione automatica dei file, impostate su winzozz, generino quel tempo CPU?

L'indicizzazione viene svolta dai processi SearchIndexer.exe e SearchProtocolHost.exe, non da explorer.exe... ci stavo pensando anch'io a cosa potesse essere ma non riesco a trovare una spiegazione che mi soddisfi... poi senza pc sottomano è ancora più difficile!