ARGOMENTO:

Non ho la più pallida idea di cosa significhino le ultime 5 impostazioni nelle preferenze, e non le avevo neanche notate finora

Avete un programma per vedere il carico della GPU su ubuntu?che se non è usata al 100% non sono contento
P.S. oggi mi sono arrivate 4/5 WU GPU che sono durate 3 (al posto dei soliti 35) minuti e mi hanno dato gli stessi crediti di quelle normali

Rick! ha scritto:

Non ho la più pallida idea di cosa significhino le ultime 5 impostazioni nelle preferenze, e non le avevo neanche notate finora

Boh, portando la frequenza (*) da 60 fps (che dovrebbe essere il default preimpostato, ma il campo era vuoto) ad 40 la WU successiva viene eseguita al 99% di load anche se con qualche buchetto qua e là (prima andava al 50 60%), ma la temperatura sale a 80°C e poi le successive inspiegabilmente vanno all'80 85% circa mah
spetta ... ora va di nuovo al 99% ri-boh, forse il carico dipende dalla WU, ogni tanto ne fà qualcuna isolata al 99% e poi altre all'80 ...
dopo cena provo con l'app_info


(*)

Frequency (in Hz) that should try to complete individual work chunks. Higher numbers may run slower but will provide a more responsive system.
Lower may be faster but more laggy.
default 60 (corresponds to 60 fps)

Ho provato l'app_info ma mi sà che ha rotto tutto,
oltre a non caricare le 2 WU sul milkway (ora ho resettato il progetto e non carica più WU), anche il POEM fà cose strane, si mette ad elaborare 2 WU per volta invece che le 6 impostate il progetto CPU non libera nessuno dei 4 core, solo se lo metto in pausa partono tutte le 6 WU impostate sull'app_info del POEM ...
possibile che ci sia qualche variabile globale che registra l'uso di app_info e quando avviene su progetti multipli fà casino ?

EDIT

Risolto!
Era la maledetta 7.0.64 ... a seguito degli smenttamenti sul milkway le WU CPU del simap erano andate in stato "running, high priority" e questo sulla 64 fa si che il progetto CPU usi tutti i core a discapito del progetto GPU in app_info che quindi si ferma. Rimettendo la 7.0.28 il simap ha ricominciato ad usare un solo core e POEM a elaborare le su 6 WU in parallelo.
Certo che hanno introdotto un bel baco, non credo che nessuno voglia stoppare il lavoro sulla GPU se ci sono delle WU ad alta priorità lato CPU ... mah

Ah ecco!!!!
Nei giorni scorsi sono impazzito per stargli dietro, fra docking in highprioriry e poem che non riusciva a lavorare.

Avevo fatto una ricerca e nel wiki ho visto un flag per l'alta priorità, ma non ho ancora approfondito.
Però se le cose stanno così come dici torno subito alla 28 pure io

astroale ha scritto:

Ho provato l'app_info ma mi sà che ha rotto tutto,
oltre a non caricare le 2 WU sul milkway (ora ho resettato il progetto e non carica più WU), anche il POEM fà cose strane, si mette ad elaborare 2 WU per volta invece che le 6 impostate il progetto CPU non libera nessuno dei 4 core, solo se lo metto in pausa partono tutte le 6 WU impostate sull'app_info del POEM ...
possibile che ci sia qualche variabile globale che registra l'uso di app_info e quando avviene su progetti multipli fà casino ?

EDIT

Risolto!
Era la maledetta 7.0.64 ... a seguito degli smenttamenti sul milkway le WU CPU del simap erano andate in stato "running, high priority" e questo sulla 64 fa si che il progetto CPU usi tutti i core a discapito del progetto GPU in app_info che quindi si ferma. Rimettendo la 7.0.28 il simap ha ricominciato ad usare un solo core e POEM a elaborare le su 6 WU in parallelo.
Certo che hanno introdotto un bel baco, non credo che nessuno voglia stoppare il lavoro sulla GPU se ci sono delle WU ad alta priorità lato CPU ... mah

Se la guardi dal lato di non voler far scadere le wu ci sta secondo me

Rick! ha scritto:

Ah ecco!!!!
Nei giorni scorsi sono impazzito per stargli dietro, fra docking in highprioriry e poem che non riusciva a lavorare.

Avevo fatto una ricerca e nel wiki ho visto un flag per l'alta priorità, ma non ho ancora approfondito.
Però se le cose stanno così come dici torno subito alla 28 pure io

Mi sono dato uno sguardo al WIKI di boinc sulla configurazione:
boinc.berkeley.edu/wiki/Client_configuration

Nel mio file ho AGGIUNTO <fetch_on_update>1</fetch_on_update> nelle options ed ho MODIFICATO A 1 il parametro <no_priority_change>1</no_priority_change>

Non serve riavviare, basta "Leggi il file di configurazione" dal menu "Avanzate"

Stavo cercando di prendere almeno 1 WU di GPUGRID e il tutto era sballato da Milky che si conferma sbagliare del tutto i tempi stimati (15 minuti contro un reale di 3, su GPU).


Modificando il no_priority_change finalmente dal log è sparito il mex della priorità:

13/06/2013 09:37:55 | GPUGRID | update requested by user
13/06/2013 09:37:55 | GPUGRID | update requested by user
13/06/2013 09:37:59 | GPUGRID | Sending scheduler request: Requested by user.
13/06/2013 09:37:59 | GPUGRID | Not requesting tasks: project is not highest priority
13/06/2013 09:38:01 | GPUGRID | Scheduler request completed
13/06/2013 09:45:53 | GPUGRID | update requested by user
13/06/2013 09:45:56 | GPUGRID | Sending scheduler request: Requested by user.
13/06/2013 09:45:56 | GPUGRID | Not requesting tasks: project is not highest priority
13/06/2013 09:45:58 | GPUGRID | Scheduler request completed
13/06/2013 09:48:03 | | Project communication failed: attempting access to reference site
13/06/2013 09:48:05 | | Internet access OK - project servers may be temporarily down.
13/06/2013 10:00:44 | | Re-reading cc_config.xml
13/06/2013 10:00:44 | | Not using a proxy
13/06/2013 10:00:44 | | Config: run apps at regular priority
13/06/2013 10:00:44 | | Config: report completed tasks immediately
13/06/2013 10:00:44 | | Config: fetch on update
13/06/2013 10:00:44 | | log flags: file_xfer, sched_ops, task
13/06/2013 10:01:31 | GPUGRID | update requested by user
13/06/2013 10:01:32 | GPUGRID | Sending scheduler request: Requested by user.
13/06/2013 10:01:32 | GPUGRID | Not requesting tasks
13/06/2013 10:01:34 | GPUGRID | Scheduler request completed

e finalmente:

13/06/2013 10:01:34 | GPUGRID | Scheduler request completed
13/06/2013 10:08:04 | GPUGRID | Sending scheduler request: To fetch work.
13/06/2013 10:08:04 | GPUGRID | Requesting new tasks for NVIDIA
13/06/2013 10:08:06 | GPUGRID | Scheduler request completed: got 1 new tasks

Non so però se dipende dal flag o dal fatto che cmq avevo interrotto il fetch su Milky.
Questi sono i 2 prj GPU che ho attivi al momento, per i prj CPU la nota "project is not highest priority" continua ad uscire (almeno su Leiden e su FightMalaria)

Qualcun altro vuole provarci?


EDIT
Googolando ho trovato un suggerimento e l'ho seguito: impostare il MinimumWorkBuffer a 1 e l'Additional a 0.1
La versione 7 lavora molto "meglio" sulla stima dei tempi e gestisce priorità e riserva di lavoro in maniera molto più coerente con le riserve richieste di come non facesse la versione 6
Da qui i problemi che genera Milky

Rick! ha scritto:

Ah ecco!!!!
Nei giorni scorsi sono impazzito per stargli dietro, fra docking in highprioriry e poem che non riusciva a lavorare.

Avevo fatto una ricerca e nel wiki ho visto un flag per l'alta priorità, ma non ho ancora approfondito.
Però se le cose stanno così come dici torno subito alla 28 pure io

Da perfetto sclerotico mi ero dimenticato che la cosa mi era già capitata sul PC della 5770, su questo della 4770 inizialmente ero riuscito a risolvere abortendo le WU in high priority e così non avevo più fatto il downgrade. Ora non l'ho fatto perchè avevo WU molto lunghe e mi seccava buttare via molte ore di CPU.

Stanno rilasciando una nuova versione di Separation. La nuova versione verrà scaricata con nomi differenti perchè funzionerà con un accesso modificato, vogliono abilitare le WU a usare i nuovi e i vecchi accessi.

Se ci sono problemi con le WU "milkyway_separation__modified_fit" postate sul forum.

Con questo aggiornamento sono supportate le seguenti piattaforme:

Linux 32-bit : Periferiche con doppia precisione che supportano OpenCL , CPU

Linux 64-bit: Periferiche con doppia precisione che supportano OpenCL , CPU

Windows 64-bit: Periferiche con doppia precisione che supportano OpenCL , CPU

MacOSX: Periferiche con doppia precisione che supportano OpenCL , CPU

Sperano di poter aggiungere Windows 32-bit tra poco.

Io continuo a non ricevere niente per la mia HD4850...

Io niente Separation per CPU

Gattorantolo ha scritto:

Io continuo a non ricevere niente per la mia HD4850...

Serve ancora la doppia precisione anche con i nuovi client?

morse ha scritto:

Gattorantolo ha scritto:

Io continuo a non ricevere niente per la mia HD4850...

Serve ancora la doppia precisione anche con i nuovi client?

a me non e' comparso il solito "your CPU lacks of...." pero' .. .non vuol dir niente

Ho questo app_config per milky, mi fa le milky in ~500 secondi e le Separation in ~1250

E ogni tanto freeza il monitor (perdo anche il cursore del mouse).

Qualcun altro ha esperienza di app_config sulla 570???

Rick! ha scritto:

Ho questo app_config per milky, mi fa le milky in ~500 secondi e le Separation in ~1250

E ogni tanto freeza il monitor (perdo anche il cursore del mouse).

Qualcun altro ha esperienza di app_config sulla 570???

<app_config>
   <app>
      <name>milkyway_separation__modified_fit</name>
      <max_concurrent>4</max_concurrent>
      <gpu_versions>
          <gpu_usage>.25</gpu_usage>
          <cpu_usage>.25</cpu_usage>
      </gpu_versions>
    </app>
   <app>
      <name>milkyway</name>
      <max_concurrent>4</max_concurrent>
      <gpu_versions>
          <gpu_usage>.25</gpu_usage>
          <cpu_usage>.25</cpu_usage>
      </gpu_versions>
    </app>
</app_config>

Il file mi sembra corretto. Secondo me è un problema con i driver il discorso del freeze oppure carichi troppo la gpu

milkyway.cs.rpi.edu/milkyway/result.php?resultid=568353326
milkyway.cs.rpi.edu/milkyway/result.php?resultid=568310009
milkyway.cs.rpi.edu/milkyway/result.php?resultid=568273746
milkyway.cs.rpi.edu/milkyway/result.php?resultid=568170272
milkyway.cs.rpi.edu/milkyway/result.php?resultid=568167983
milkyway.cs.rpi.edu/milkyway/result.php?resultid=568158512
milkyway.cs.rpi.edu/milkyway/result.php?resultid=568160584
.
.
.


come mai mi vanno tutte in errore??

dome92 ha scritto:

milkyway.cs.rpi.edu/milkyway/result.php?resultid=568353326
milkyway.cs.rpi.edu/milkyway/result.php?resultid=568310009
milkyway.cs.rpi.edu/milkyway/result.php?resultid=568273746
milkyway.cs.rpi.edu/milkyway/result.php?resultid=568170272
milkyway.cs.rpi.edu/milkyway/result.php?resultid=568167983
milkyway.cs.rpi.edu/milkyway/result.php?resultid=568158512
milkyway.cs.rpi.edu/milkyway/result.php?resultid=568160584
.
.
.


come mai mi vanno tutte in errore??

mmm non vorrei che il problema sia XP e i driver troppo vecchi

sembrano errori di accesso alla memoria (ma forse anche mi sbaglio )

cmq la tua conf a me funziona.

hai modificato le preferenze dal sito ?

Ho appena colto sul fatto una WU di GPUGRID (senza app_config) e 2 di Milky (con app_config) eseguite simultaneamente.
Vi è mai capitato?

Rick! ha scritto:

Ho appena colto sul fatto una WU di GPUGRID (senza app_config) e 2 di Milky (con app_config) eseguite simultaneamente.
Vi è mai capitato?

...strano, di solito GPUGRID si ciuccia l`intera GPU...