CPU resource share @GPU0 GPU1 etc.

Diskusia ohľadom inštalácie, riešenia problémov, nových verzií, optimalizácie atď.

Moderátor: Moderátori

Používateľov profilový obrázok
Kiwi
Príspevky: 2072
Dátum registrácie: Ut Feb 13, 2007 4:18 pm
Bydlisko: Sobrance
Kontaktovať používateľa:

CPU resource share @GPU0 GPU1 etc.

Príspevok od používateľa Kiwi »

Ako nastavit, aby 1 jadro bolo priradene 1. GPU, dalsie jadro 2. GPU a ostatne jadra CPU projektom ?
Používateľov profilový obrázok
MeX
Site Admin
Príspevky: 485
Dátum registrácie: Po Feb 05, 2007 2:13 pm
Bydlisko: Bratislava, Slovensko
Kontaktovať používateľa:

Re: CPU resource share @GPU0 GPU1 etc.

Príspevok od používateľa MeX »

Nie som si isty, ci Tvoja otazka ma zmysel. GPU "zerie" z CPU v podstate nic - zalezi od projektu. Ja co som skusal tak to boli bud naozaj iba jednotky percent alebo naozaj skoro nic. Myslim ze vyhradit cely core len pre GPU by bola skoda. Kazdopadne mozes nastavit (priamo cez manager) pocet corov z celkoveho poctu pouzitelnych pre BOINC a tak to obmedzit.
Používateľov profilový obrázok
Kiwi
Príspevky: 2072
Dátum registrácie: Ut Feb 13, 2007 4:18 pm
Bydlisko: Sobrance
Kontaktovať používateľa:

Re: CPU resource share @GPU0 GPU1 etc.

Príspevok od používateľa Kiwi »

No PG zerie na GPU1 aj GPU2 0.66 cpu resources, ked vypnem malariu, tak obe GPUs idu
na 99 % a casy su akolo 1700 sec, ak zapnem malariu na 8 threadov, tak vyuziva GPUs na
69 az 80 % a casy su nad 2600 sec.

Takze keby som dal 2 jadra PG na managemet GPUs, tak by mi ostalo 6 na malariu a obe
GPU by isli naplno.

V MW a Collatz je to len 0.05 CPU, ale tu je to 2 x 0.66.

SKusal som hladat nejaky app_info.xml a dal som tam max. 0.05 cpus, ale nepomohlo.
Používateľov profilový obrázok
MeX
Site Admin
Príspevky: 485
Dátum registrácie: Po Feb 05, 2007 2:13 pm
Bydlisko: Bratislava, Slovensko
Kontaktovať používateľa:

Re: CPU resource share @GPU0 GPU1 etc.

Príspevok od používateľa MeX »

Mas na mysli 8 jadier alebo 8 threadov? Pretoze ak sa jedna o HT tak potom sa nemozes divit ze pri zatazeni 4 threadov mas 100% load :).
Používateľov profilový obrázok
Palo M.
Príspevky: 1200
Dátum registrácie: Po Feb 12, 2007 2:53 am
Bydlisko: Shanghai, China

Re: CPU resource share @GPU0 GPU1 etc.

Príspevok od používateľa Palo M. »

Problem je inde, ja sam som s tym trocha bojoval pri Collatzi:
- Ak som spustil v pozadi (ako daemon) BOINC len pre vsetky jadra CPU a potom samostatneho druheho klienta len pre CPU, GPU bolo vytazene na 85-90% (a CPU samozrejme 4x 100%). Boli spustene 2 procesy core-klientov boinc, kazdy pocuval na inom GUI-porte a dokonca bezali pod inymi user-ID. Dve rozne machine-ID, v jednom klientovi bezali len CPU projekty a v druhom zasa len Collatz. Ti klienti boli uplne oddeleni.
- Ked som dal vsetko do jedneho klienta, aj CPU aj GPU, sice to bezalo, ale GPU len na 50-55% a tomu sa aj zodpovedajuco predlzoval cas vypoctu. Skratka GPU sa flakalo. CPU islo uplne rovnako.

Podstata problemu: GPU nedostavalo dost dat, preto cakalo. Na krmenie GPU sa pouziva ta mala cast CPU, ale ta sa musela delit s CPU-projektami o cas a skratka nestihala dodavat dostatocne rychlo data pre GPU. Respektive, integrovana grafika (slaba HD 3300) bezala na 100% v obidvoch pripadoch (tej stihalo dodavat tu trochu dat), kym samostatna grafika (HD4870 1G) zjavne nemala dost dat.

Preco to nerobilo, ked mi to bezalo oddelene? Lebo CPU-projekty bezali v pozadi (spustalo sa z init.d), s nice 19, kym GPU cast som spustal manualne skriptom, az potom, co som sa prihlasil do Gnome. Bez nice, takze s vyssou prioritou.

Riesenie: Trocha sa pohrat s init.d skriptom (ktory teraz spusta BOINC) a upravit volanie schedule tak, aby nenastavovalo boinc-u a vsetkym jeho childom rovnako znizenu prioritu.
Bohuzial, stale to nechodi idealne. Lebo boinc sa spusta prakticky zaroven s gdm, uzivatel pod ktorym bezi sice ma pravo pristupu na X-server, ale kym sa neprihlasim do Gnome a manualne nerestartnem BOINC (robim cez sudo /etc/init.d/boinc-client restart, sudo mam nastavene tak, ze pre tento prikaz ani nepyta heslo), tak az do takeho restartu aj GPU jednotky bezia s blbou prioritou. Asi v tom hra ulohu X-server, ale neprisiel som na to, co konkretne je zodpovedne za to, ze ked to spusti prihlaseny user, tak to ide perfektne, ale ked sa to spusti automaticky v case ked nikto nie je prihlaseny, tak sa to sprava inac (v oboch pripadoch boinc aj tak bezi pod tym userom, ktory je len na boinc, nie pod interaktivnym userom). Mozno ked nie je nikto prihlaseny, tak nevie GPU aplikacia nastartovat 3D-mod grafiky, tak to nemoze ist naplno...
Obrázok
---
Obrázok
"Ostatně, kdybych si měl vybrat pořadí Mac OS X, Windows, Linux, tak to bude: Linux, Mac OS X, sebevražda, Windows." (úryvok z internetovej diskusie)
Používateľov profilový obrázok
Kiwi
Príspevky: 2072
Dátum registrácie: Ut Feb 13, 2007 4:18 pm
Bydlisko: Sobrance
Kontaktovať používateľa:

Re: CPU resource share @GPU0 GPU1 etc.

Príspevok od používateľa Kiwi »

Diky za rady. V Ubuntu to vysusam, ale tu sa mi jedna o Win 7.
Ak ide Collatz, tak obe GPUs idu na 97 % a je to ok, ale ak dam PG, tak to skace od 70 do 98 %, tych
98 % ide len jedna GPU a druha sa flaka a opacne.
Da sa nejako nastavit, aby v okamihu, ked sa GPU uvolni, znova dostala data od CPU a nemusela tych
par ms cakat ?
Mozno by to slo zvacsenim CPU zatazenia z 0.66 na 0.75 apod. Ale ako vyrobit pre PG vo Win 7 app_info.xml,
aby mi to neznicilo celu cache WUs ?
Používateľov profilový obrázok
Palo M.
Príspevky: 1200
Dátum registrácie: Po Feb 12, 2007 2:53 am
Bydlisko: Shanghai, China

Re: CPU resource share @GPU0 GPU1 etc.

Príspevok od používateľa Palo M. »

Vo Windoze teda neviem, ale skusil by som sa manualne hrat s prioritami procesov. Teda CPU-aplikaciam by som nastavil uplne najnizsiu moznu prioritu a BOINC managerovi a GPU aplikaciam by som nastavil o nieco vyssiu. Myslim, ze XPcka mali pod normalnou prioritou este 3 rozne nizsie priority, tak snad maju aj Win7... No a ked bude s takymito prioritami zataz GPU stabilne vyssia, tak prave priority procesov su dovod. Co s tym potom, to netusim, lebo fakt neviem, ako automaticky nastavovat priority procesov vo Win7...
Obrázok
---
Obrázok
"Ostatně, kdybych si měl vybrat pořadí Mac OS X, Windows, Linux, tak to bude: Linux, Mac OS X, sebevražda, Windows." (úryvok z internetovej diskusie)
shafa
Príspevky: 391
Dátum registrácie: So Nov 08, 2008 1:11 am

Re: CPU resource share @GPU0 GPU1 etc.

Príspevok od používateľa shafa »

Asi to nesouvisi uplne s tematem, ale nechci kvuli tomu zadavat nove tema - kdyztak to smazte.

Vetsinou nedavam stejne prispevky do vice for, ale toto je pomerne zajimave - rozdil v chovali klienta pro Win a Linux.
Setkali jste se s tim taky?
If someone asked me to choose between Metallica and Megadeth, I would say SLAYER...
Používateľov profilový obrázok
Palo M.
Príspevky: 1200
Dátum registrácie: Po Feb 12, 2007 2:53 am
Bydlisko: Shanghai, China

Re: CPU resource share @GPU0 GPU1 etc.

Príspevok od používateľa Palo M. »

Nepochopil som otazku, co vlastne chces dosiahnut - to s tym obmedzovanim jadier... Ved nech pocitaju vsetky, nie? 8)

Ja ale tak ci tak pouzivam pre GPU app_info.xml
A tiez na podporu GPU jednotky je treba iba velmi malo CPU, takze ma vobec netrapi, odkial sa zoberie (akurat som musel nechat vyssiu prioritu GPU taskom, inak boli spomalovane cakanim na CPU).
Takto to vyzera na (headless) masine so SETI na Nvidii (na tomto stroji app_info.xml pre SETI pouzivam kvoli optimalizovanej astropulse aplikacii):

Kód: Vybrať všetko

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 4899 boinc     39  19  354m 118m 8680 R  101  5.9  23:07.32 wcgrid_cep2_qch
 9173 boinc     39  19  315m  60m 9104 R  101  3.0   2:32.95 wcgrid_cep2_qch
18011 boinc     39  19  308m  82m 9.8m R  101  4.1  77:21.03 wcgrid_cep2_qch
29485 boinc     39  19  479m 413m 7112 R   95 20.6 191:01.71 minirosetta_3.1
 2267 boinc     39  19  170m 104m  20m S    2  5.2   1:31.17 setiathome-CUDA
A takto na desktope (1x on-board HD4200 + 1x separatna HD4870) s ATI na Collatz (tu app_info.xml pre Collatz potrebujem kvoli samotnej GPU aplikacii, projekt by mi ju neposlal):

Kód: Vybrať všetko

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
19125 boinc     39  19  101m  96m 1328 R   99  2.4  15:43.96 einstein_S6Buck
21955 boinc     39  19  318m  65m 9092 R   97  1.6   2:07.10 wcgrid_cep2_qch
21931 boinc     39  19 42964  39m 1052 R   95  1.0   2:56.58 wcg_dsfl_vina_6
19120 boinc     39  19  470m 414m  14m R   89 10.5  15:45.24 minirosetta_3.1
19121 boinc     20   0  120m  59m 9.9m R    4  1.5   0:10.14 collatz_2.01_x8
19108 boinc     20   0  120m  62m  13m S    2  1.6   0:29.56 collatz_2.01_x8
Ked som dal na desktope v Advanced->Preferences use at most 50.00% of processors (toto si mal na mysli s tym obmedzovanim?), tak to vyzera takto:

Kód: Vybrať všetko

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
19120 boinc     39  19  470m 414m  14m R  101 10.5  32:09.08 minirosetta_3.1
24910 boinc     39  19  353m 115m 8900 R  101  2.9   3:33.04 wcgrid_cep2_qch
23778 boinc     20   0  120m  62m  13m S    6  1.6   0:21.73 collatz_2.01_x8
19121 boinc     20   0  120m  59m 9.9m S    2  1.5   0:23.58 collatz_2.01_x8
Takze u mna to vyzera tak, ze to co potrebuju GPU jednotky, je "navyse".
Podla mna je to skratka tak, ze sa odstartuju patricne procesy a hotovo, potom sa tie procesy uz len "biju" o procesor...
Obrázok
---
Obrázok
"Ostatně, kdybych si měl vybrat pořadí Mac OS X, Windows, Linux, tak to bude: Linux, Mac OS X, sebevražda, Windows." (úryvok z internetovej diskusie)
shafa
Príspevky: 391
Dátum registrácie: So Nov 08, 2008 1:11 am

Re: CPU resource share @GPU0 GPU1 etc.

Príspevok od používateľa shafa »

No, jadra nepocitaji na nekolika PC vsecky zejmena z duvodu hluku chladicu (sice mirneho, ale prece jen slysitelneho).
Dale taky ze jsem liny si detailne hrat s nastavovovanim priorit procesu pro gpu a resim to tim ze jedno jadro jede vlastne jen pro gpu a "zbytek sveta".

Kdyz jsem si v linuxu nice gpu procesu zmenil rucne, tak to na rychlost pocitani grafiky nemelo zas takovy vliv, jako primo odstaveni jednoho jadra od cpu vypoctu.
Einstein si na jednu gpu jednotku bere cca 20% jednoho jadra procaku.

Srovnavanim vytizeni ve win a linuxu jsem prave dosel ke zjisteni, ze se to chova jinak. A to pomerne zajimave - jak jsem psal -
pokud nastavim v preferencich na linuxu na 2 jadrovem cpu jen 50% procesoru, tak druhe jadro nedela vubec nic. Ve win na nem jede uloha pro gpu (20% jadra).

Omezovani: - tools - computing preferences - boinc manager-preferences - on multiproc systems use at most xyz% of the processors
myslim ze mas jen malinko starsi verzi managera, ale jedna se o to same.

Ono to jde totiz omezit i v app_info:
<avg_ncpus>1.000000</avg_ncpus>
<max_ncpus>1.333333</max_ncpus>
tzn. jednou mi jen 3 jadra na cpu vypocty a ctvrte mele 2 ulohy pro gpu jednotky, coz mu zabere 40%.
Prílohy
screen.png
screen.png (31.35 KiB) 17345 zobrazení
If someone asked me to choose between Metallica and Megadeth, I would say SLAYER...
Používateľov profilový obrázok
Palo M.
Príspevky: 1200
Dátum registrácie: Po Feb 12, 2007 2:53 am
Bydlisko: Shanghai, China

Re: CPU resource share @GPU0 GPU1 etc.

Príspevok od používateľa Palo M. »

Tak uz zacinam rozumiet tvojej motivacii :-) Ja som riesil nieco podobne, lebo ATI GPU mi pocitala len na nejakych 45% vytazenia kvoli tomu, ze proces mal uplne rovnaku prioritu ako CPU-tasky a grafika nebola dostatocne krmena datami, takze sa flakala.

Podla vsetkeho app_info.xml ma najvyssiu prioritu - pomocou neho mozes "povedat boinc klientovi, ze cierne je biele". Ako sa to sprava bez app_info.xml bohuzial nemozem vyskusat, bez neho mi to nepojde... ale v pripade Einsteina podla mna posiela tieto nastavenia projekt (treba pozriet, co mas v client_state.xml)... a ked projekt posle 40% CPU a 1.00x ATIGPU, tak sa mi zda len logicke, ze to klient pri planovani zohladni do celkoveho mnozstva CPU, ktore ma nastavene... ci do celkoveho mnozstva zohladnuje info z app_info.xml neviem, ale cez app_info.xml sa dala spustit ATI aplikacia este v case, ked klient samotny o ATI ani nechyroval (ale bolo nutne nastavit tam nejake cmd-line parametre, co teraz uz netreba)...

So sa tyka priorit v linuxe, tak som zistil, ze klient manazuje priority procesov sam. Lenze do toho byvaju v linuxovych distribuciach rozne init-skripty na BOINC a tie to cele rozsahaju tym, ze vnucuju nice level a podobne hluposti, takze potom to cele nezafunguje uplne tak, ako tvorcovia BOINC zamyslali - ja som v tych init-skriptoch patricne "scheduling" kraviny zakomentoval tam, kde pouzivam GPU (ked sa pouziva len CPU, tak je ten scheduling zase velmi uzitocny, lebo dava BOINC-u najmensiu prioritu, teda BOINC nebrzdi ine tasky). To sa ale lisi od distribucie, ja mam na desktope Ubuntu a na serveroch Debian a uz u tychto dvoch (inak velmi podobnych) je to urobene inac. Ale viac ako priorita procesu (ktora sa da nastavit cez nice), je dolezity scheduling class, ten musi mat GPU aplikacia vyssi ako CPU aplikacia...

Takze podla mojich skusenosti sa vlastne netreba "detailne hrat s nastavovanim priorit", staci odposlat do prec nastavovanie z distribucie a nechat to na samotneho klienta.

Ked som odfajcil "distribucne vylepsovaky", tak to vyzera takto na masine s Nvidiou (Debian 6.0):

Kód: Vybrať všetko

# /etc/init.d/boinc-client status
Status of BOINC core client: running.
Scheduling of BOINC core client: 27898.
pid 27898's current scheduling policy: SCHED_OTHER
pid 27898's current scheduling priority: 0
Scheduling of BOINC core client's children: 1912 7822 8688 19326 22848 30588.
pid 1912's current scheduling policy: SCHED_OTHER
pid 1912's current scheduling priority: 0
pid 7822's current scheduling policy: SCHED_OTHER
pid 7822's current scheduling priority: 0
pid 8688's current scheduling policy: SCHED_BATCH
pid 8688's current scheduling priority: 0
pid 19326's current scheduling policy: SCHED_BATCH
pid 19326's current scheduling priority: 0
pid 22848's current scheduling policy: SCHED_BATCH
pid 22848's current scheduling priority: 0
pid 30588's current scheduling policy: SCHED_BATCH
pid 30588's current scheduling priority: 0
OOM killer status for BOINC core client:.
PID 27898: adj 0, score 34318
PID 1912: adj 0, score 43752
PID 7822: adj 0, score 7920
PID 8688: adj 0, score 79782
PID 19326: adj 0, score 52140
PID 22848: adj 0, score 8436
PID 30588: adj 0, score 5910
# ps -o "pid,ppid,pcpu,cls,pri,nice,psr,comm" -u boinc
  PID  PPID %CPU CLS PRI  NI PSR COMMAND
 1912 27898 12.9  TS   0  19   3 setiathome-CUDA
 2880 30588  2.0   B   0   -   1 wcg_dsfl_vina_6
 2884  2880  0.0   B   0   -   1 wcg_dsfl_vina_6
 2885  2884 98.5   B   0   -   1 wcg_dsfl_vina_6
 7822 27898  0.2  TS   0  19   0 data_collect_v3
 8688 27898  0.0   B   0   -   0 wcgrid_cep2_6.4
 8689  8688  0.0   B   0   -   0 wcgrid_cep2_6.4
 8690  8689  0.0  TS   0  19   3 wcgrid_cep2_6.4
10459  8688 55.8   B   0   -   0 wcgrid_cep2_qch
10460 10459  0.0   B   0   -   2 wcgrid_cep2_qch
10461 10460  0.0  TS   0  19   0 wcgrid_cep2_qch
19326 27898  0.0   B   0   -   0 wcgrid_cep2_6.4
19327 19326  0.0   B   0   -   0 wcgrid_cep2_6.4
19328 19327  0.0  TS   0  19   3 wcgrid_cep2_6.4
22848 27898 53.1   B   0   -   3 minirosetta_3.1
27131 19326 98.8   B   0   -   2 wcgrid_cep2_qch
27132 27131  0.0   B   0   -   2 wcgrid_cep2_qch
27133 27132  0.0  TS   0  19   0 wcgrid_cep2_qch
27898     1  0.1  TS   0  19   1 boinc
30588 27898  0.5   B   0   -   0 wcg_dsfl_6.19_i
30589 30588  0.0   B   0   -   2 wcg_dsfl_6.19_i
30590 30589  0.0  TS   0  19   0 wcg_dsfl_6.19_i
A takto na masine s ATI (Ubuntu 10.4):

Kód: Vybrať všetko

$ sudo /etc/init.d/boinc-client status
 * Status of BOINC core client: running
 * Scheduling of BOINC core client: 15163
PID 15163: PRIO   0, POLICY N: SCHED_NORMAL  , NICE  19, AFFINITY 0xf
 * Scheduling of BOINC core client's children:  1750  7551 10219 10302 11162 12767 
PID  1750: PRIO   0, POLICY B: SCHED_BATCH   , NICE  19, AFFINITY 0xf
PID  7551: PRIO   0, POLICY B: SCHED_BATCH   , NICE  19, AFFINITY 0xf
PID 10219: PRIO   0, POLICY B: SCHED_BATCH   , NICE  19, AFFINITY 0xf
PID 10302: PRIO   0, POLICY N: SCHED_NORMAL  , NICE   0, AFFINITY 0xf
PID 11162: PRIO   0, POLICY N: SCHED_NORMAL  , NICE   0, AFFINITY 0xf
PID 12767: PRIO   0, POLICY B: SCHED_BATCH   , NICE  19, AFFINITY 0xf
 * OOM killer status for BOINC core client:
PID 15163: adj 15, score 5909053440
PID 1750: adj 15, score 146669568
PID 7551: adj 15, score 1354170368
PID 10219: adj 15, score 388235264
PID 10302: adj 15, score 336691200
PID 11162: adj 15, score 126386176
PID 12767: adj 15, score 147128320
$ ps -o "pid,ppid,pcpu,cls,pri,nice,psr,comm" -u boinc
  PID  PPID %CPU CLS PRI  NI PSR COMMAND
 1750 15163 47.3   B   0   -   1 minirosetta_3.1
 3352  7551 96.4   B   0   -   2 wcgrid_cep2_qch
 3353  3352  0.0   B   0   -   0 wcgrid_cep2_qch
 3356  3353  0.0  TS   0  19   0 wcgrid_cep2_qch
 7551 15163  0.0   B   0   -   0 wcgrid_cep2_6.4
 7552  7551  0.0   B   0   -   1 wcgrid_cep2_6.4
 7553  7552  0.0  TS   0  19   2 wcgrid_cep2_6.4
10219 15163  0.5   B   0   -   2 wcg_dsfl_6.19_i
10220 10219  0.0   B   0   -   0 wcg_dsfl_6.19_i
10221 10220  0.0  TS   0  19   2 wcg_dsfl_6.19_i
10302 15163  3.4  TS  19   0   2 collatz_2.01_x8
11162 15163  1.1  TS  19   0   0 collatz_2.01_x8
12767 15163 75.2   B   0   -   3 hsgamma_FGRP1_0
15163     1  0.1  TS   0  19   3 boinc
20704 10219  2.0   B   0   -   0 wcg_dsfl_vina_6
20705 20704  0.0   B   0   -   2 wcg_dsfl_vina_6
20706 20705 93.8   B   0   -   0 wcg_dsfl_vina_6
Pole CLS je "zasifrovane" takto:
TS SCHED_OTHER (normalne)
B SCHED_BATCH (nizsia priorita)

Pole PSR je cislo procesora. Kvoli optimalizaciam sa spustaju rozne podprocesy k jednej WU a je to rozhadzane vselijako medzi jadra (zorientovat sa da cez PPID), ale podla GPU-WU sa da najst na ktorom CPU bezi a co tam bezi s nim... Takze ked sa pokusas vysledovat, co je na ktorom jadre, skus pouzit prikaz ps podobne...

Inak mam taku domnienku, ze pri niektorych CPU-aplikaciach by mohlo pomoct nastavit CPU-affinity, aby jedna jednotka bezala len na jednom konkretnom jadre - v pripade, ze sa vyuziva vo zvysenej miere cache procesora a migrovanim vypoctu z jedneho jadra na druhe sa potencial cache nemoze vyuzit...
Tu affinitu by ale musel nastavovat sam klient - a tiez to niekde moze priniest nevyhodu, ak je jedno jadro vytazene mimo BOINC (uplne inym procesom), tak by taka jednotka viazana na to konkretne jadro trvala omnoho dlhsie - takze by to bolo vhodne len pre hardcore-crunching s dedikovanou masinou na BOINC.
Obrázok
---
Obrázok
"Ostatně, kdybych si měl vybrat pořadí Mac OS X, Windows, Linux, tak to bude: Linux, Mac OS X, sebevražda, Windows." (úryvok z internetovej diskusie)
Napísať odpoveď