ARGOMENTO:

---

Homepage	Articolo sul portale	Pagina delle statistiche	Pagina delle applicazioni	Join del Team	Stato del server

---

da notare che questo progetto è nato grazie alla pubblicazione dei risultati di 3x+1, dopo la morte del progetto stesso

direttamente dal loro forum, l' amministratore dice :

"Note: This project is not for commercial purposes, nor it is related to any academic research. It was created because. That's it. Just because."

Quindi direi che parte offrendo ben poche garanzie.
Per ora si osserva senza partecipare, dico bene?

Ducati 749 ha scritto:

da notare che questo progetto è nato grazie alla pubblicazione dei risultati di 3x+1, dopo la morte del progetto stesso

EDIT
volevo dire che 3x+1, nonostante non avesse un'"istituzione" dietro le spalle, si è comportato molto bene: ha comunicato la chiusura, ha pubblicato i risultati e ha consentito ad altri appassionati di continuare il progetto
cit. cosa volete di più dalla vita?

Esiste un altro progetto che supporta ATI e non ne sapevo niente

Provo di corsa


A livello di serietà e professionalità, il progetto mi sembra a posto, ci sono aggiornamenti continui, riprende il lavoro del progetto precedente e lo continua inoltre propone client ottimizzati in collaborazione con crunch3r e gipsel quindi sotto questo fronte l'impegno c'è.

Il fatto che non sia affiliato a nessuna università significa poco nei casi di progetti matematici, qua la formula è semplice, serve potenza di calcolo e tanta

Questo è il progetto PERFETTO per chi ha problemi di linea/connessione

Dimensioni WU: 46 bytes in download (si, bytes)

Memoria occupata in esecuzione: 420KB Ovvero, inesistente

gabi.2437 ha scritto:

Esiste un altro progetto che supporta ATI e non ne sapevo niente

Provo di corsa

provato con CUDA e funziona egregiamente

provato con ATI (sullo stesso PC su cui scaccola allegramente MW) e tutte le WU mi vanno in errore


fammi sapere come ti va

Gabi.2437 della Flotta Stellare a rapporto!

Dopo errori e vari esperimenti, comunico il perfetto funzionamento del tutto, ma non è stato facile signore!

Qua descritte tutte le varie peripezie www.flottastellare.org/showthread.php?t=887

Comunque tutto risolto alla fine, alleluia.

Allora, come driver gli 8.12 vanno bene, se ne hai di più aggiornati vanno bene ma devi fare la solita procedura copia/incolla/rinomina di tre .dll

Poi, una volta messi al loro posto i 3 file, ti capita quell'errore perchè nel zip che si scarica c'è brook.dll, ma, guarda un pò l'applicazione cerca brook32.dll, quindi devi andar lì e rinominare brook.dll in brook32.dll avendo cura però di COPIARE il file, se no poi BOINC cerca inutilmente di scaricarlo Devi avere brook.dll e brook32.dll, fa niente se a conti fatti è lo stesso file.

Fatto ciò se avvii BOINC, dovrebbe andare, sono possibili crash dei driver, per risolvere devi armeggiare coi parametri del file app_info.xml

Riassumendo

-copia e incolla brook.dll e rinomina la copia in brook32.dll
-se hai reset dei driver (come sempre, l'applicazione è fatta per le 4870, la mia 3870 con le impostazioni base-->crash all'istante), pasticcia coi parametri

Personalmente con

<cmdline>-k256 -n1 -w7</cmdline>

qua funge tutto bene

progetto interessante...


adesso provo la mia ATI...

facci sapere

ho provato funziona tutto alla grande solo sfrutta troppa CPU...


spero migliorino la gestione della CPU!!!


comunque avanti cosi, pian piano il supporto alle GPU si estenderà anche a WCG e Rosetta!!!

Su Rosetta aspetta e spera Ammenoche qualcuno di noi non vada lì a programmare giorno e notte per ogni client che fanno (e ultimamente aggiornano il client ogni 2 settimane o giù di lì )

E' down da giorni.. Ho 25 risultati in attesa di essere rispediti..

hanno rilasciato una nuova versione che occupa solo il 5% della cpu!!!

adesso il progetto funziona egregiamente...

sarà il caso di supportarlo?dato che è il secondo progetto con supporto alle ATI?

C'è da considerare:
-one man show (progetto seguito da un solo uomo quindi a rischio chiusura)o poco di più. non sembrano esserci istituzioni dietro
-supporto pieno a cuda
-supporto pieno ad ati tramite boinc (primo progetto a farlo) senza bisogno di procedure particolari (app_info etc)
-i crediti sono elevati ma appena si sono accorti che erano troppi li hanno prima dimezzati e poi diminuiti ancora
-con la release 2 hanno cambiato algoritmo di calcolo riducendo i tempi di calcolo e allungando di conseguenza le WU
-disponibili a risolvere i problemi che gli vengono presentati nel forum
-le wu sono leggere come dimensioni e come elaborazione (su cuda permettono comunque di giocare in applicazioni 3D - altri progetti laggano pure in 2D).


Con la release 2.01 hanno risolto un bug molto fastidioso che non faceva validare le WU sospese.


Io ci elaboro da qualche giorno e per adesso non ho trovato altri seri problemi.

lodevole che stiano portando avanti il lavoro di un progetto morto grazie alla pubblicazione dei risultati di questo

io dico di premiarli

che sà da fà con sto progetto?

Una cosa che mi è piaciuta di questo progetto.

Gli avevamo segnalato alcune WU con crediti elargiti a 0

Dopo aver verificato ecco la risposta:

Validators don't make mistakes. People who write the code for the validators make mistakes.

Credit has been granted now for these listed and around 90 others that had the same issue. Now to make the correction to the validator....

Si sono presi la colpa ed hanno corretto.
Più disponibili di così..... altri progetti avrebbero ignorato la richiesta (mi è già successo).
In pratica potevano fregarsene e dedicarsi a cose più importanti ma non lo hanno fatto.


Sarà un progetto amatoriale di poche persone ma adesso è uno dei più divertenti da elaborare visto la loro disponibilità e la velocità nel prendersi carico degli errori e risolverli.

Se verrà richiesto di supportarlo io voterò si.

Edit.
Ecco il contenuto del readme

Options:

kernel frequency: f (default 30)
The application determines the size of the work packages sent to the GPU in a dynamic manner. It
tries to get the number of executed packages per second above the value specified here by
splitting them to smaller ones. The OS is completely blocked from accessing the graphics card for
the duration of one package leading to a somewhat sluggish behaviour of the user interface.
Limiting the size and therefore reducing the execution time per package creates more opportunities
for the OS to slip in between two work packages and to react to user input. The default value of
30 Hz is tuned for usability of the system. Reducing it could increase the throughput of the app
slightly.

Example:
<cmdline>f10</cmdline>
The app will try to run 10 work packages per second (limits the execution time to 100ms or shorter).


Wait factor: w (default 1.0)
The app tries to release the CPU during the the GPU computations. It does so by predicting
the runtime for the GPU calls and send the CPU thread to sleep for that time. One can manually
correct the prediction of the application with this factor. When raising it, the CPU thread
sleeps longer, decreasing the value will lead to a faster wakeup of the thread. After that time,
the polling of the GPU starts. Setting this value to 0.0 turns off the release of the CPU.
Default is of course a value of 1.0. If you see a low GPU load, you can try to decrease it (if
you have a load of 80%, set it to 0.8). If you see a high CPU load, a slight increase of this
value may help. Increase it too much and it will affect the crunching speed. You could use this
for throttling of the GPU in case the high GPU load leads to a very sluggish behaviour of the
user interface or even VPU recover events. Setting w1.1 could improve the situation (see also
the f, b and p options).

Example:
<cmdline>w1.3</cmdline>
This would increase the sleep time by 30% in relation to the prediction.


Maximum GPU RAM use: r (default 33.4)
The application allocates memory on the graphics card to store the calculated steps. Increasing
the size can offer more parallel data to process and the f option more room to get the real
setting closer to itS specified value. But you should not increase the RAM usage, if more than
one WU are processed concurrently. The value is given in percent relative to the installed amount.
Too high or too low values can crash the application, so be careful! See also the explanation
about the graphics RAM usage at the end of the readme.

Example:
<cmdline>r40</cmdline>
This would increase the maximum RAM usage to 40%.


priority: p (default 1)
All BOINC applications normally run with the lowest possible priority to not disturb other
applications. This can lead to a low GPU load, as it may be not possible to fire up the next tasks
if all cores of the CPU are under load. Raising the priority may help here. BOINC recommends a
slightly increased priority for GPU applications. This setting is the default. Possible values:
p0: idle priority, used by CPU BOINC applications
p1: normal priority in idle priority class, this is the default and recommended by BOINC for GPUs
p2: normal priority in normal priority class
p3: normal priority in high priority class, use with care!
The priority will affect how much time it takes for the the app to get back control if it releases
its time slice (see also option b).

Example:
<cmdline>p2</cmdline>
This raises the priority to normal (the same as all normal user applications have as default).


polling behavior of the GPU within the Brook runtime: b (default 1)
See the option w for starters. If that time has elapsed, the GPU polling starts. This can be done
by continously checking if the task has finished (b-1), enabling the fastest runtimes, but potentially
creating a high CPU load (a bit dependent on driver version). Second possibility is to release the time
slice allotted by the OS, so other apps can run (b0). The catch is that there is some interaction with
the priority. The time slice is only released to other tasks of the same priority. So raising the priority
effectively disables the release and the behavior is virtually identical to setting this parameter
to -1. If a raised priority and a low CPU time is wanted, one should leave it at the default of 1. This
suspends the task for at least 1 millisecond, enabling also tasks of lower priority to use the CPU in the
meantime.
Possible values:
b-1: busy waiting
b0: release time slice to other tasks of same priority
b1: release time slice for at least 1 millisecond
See also options p and w.

Example:
<cmdline>b-1</cmdline>
Enable busy waiting (no release of the time slice during polling).


The options can be combined in arbitrary order. Therefore the following argument list is valid:
<cmdline>w0.9 f20 r50 p2 b1</cmdline>
(wait factor 0.9, frequency 20Hz, 50% RAM used at max, normal priority, and CPU friendly polling)



Deprecated options (use with extreme care, will likely be removed in future versions)

Number of concurrent WUs: n (default 3)
It is possible to define the maximum number of concurrently running WUs per GPU. Default value is
three. If the BOINC client schedules more WUs to run, they are put to a wait state and not crunched
until a GPU finishes another WU. Running more than a single WU can raise the efficiency of the GPU
as the remaining CPU calculations for one WU can be hidden during the wait for the GPU of another
WU. More than 2 WUs don't help anymore and running too many WUs concurrently first slow down the
calculation and finally crash if there is not enough memory. But as mentioned, more than 2 won't
help either way. If the high GPU load leads to a very sluggish behaviour of the user interface or
even VPU recover events, limiting the app to one WU (n1) could improve the situation (look also
into the w and f options). Do not use it with an ATI aware BOINC client! It should be ignored in
that case. If you run more than one GPU project (Collatz and Milkyway), this will be a shared
setting and should be the same for both in all cases!


Example:
<cmdline>n2</cmdline>
The app will run a maximum of two WUs per GPU.

Exclusion of GPUs: x (default none)
If a certain GPU should not be used by the app, one can exclude it. The GPU number has to be in
the range 0..31. The first GPU in the system has the number 0. This option can be used multiple
times. Per default, all supported ATI GPUs are used. Do not use it with an ATI aware BOINC client!
It should be ignored in that case. But there may be some unwanted side effects.

Example:
<cmdline>x1 x2</cmdline>
The app will not use the second and the third GPU in the system.

il progetto è di piccole dimensioni ma con grande ambizione. Poi hanno dietro gente veramente tosta nello scrivere codice, quindi riescono a prendersi carico direttamente dei problemi. Stanno anche aiutando molto bene nello sviluppo di boinc, aggiornando le applicazioni di continuo solo per provare tutte le ultimissime novità del ramo 6.10 di cui poi tutti beneficeranno. Un plauso ai ragazzi di Collatz Conjecture

Suggerirei di creare il team per questo progetto, visto che è, insieme a milkyway, uno degli unici progetti ATI su BOINC

gabi.2437 ha scritto:

Suggerirei di creare il team per questo progetto, visto che è, insieme a milkyway, uno degli unici progetti ATI su BOINC

vuoi essere il referente?