[Dnet] GPU Client

[aKra]

En toen was hij weer verlopen

[SandStar]

aKra schreef op maandag 02 februari 2009 @ 12:49:
En toen was hij weer verlopen

der is toch gewoon een nieuwe?

[aKra]

klopt

[spNk]

Wel jammer dat ze nog steeds geen officiële (beta) Stream client uitgebracht hebben, de 4800 serie doet het namelijk stukken sneller dan de nv serie in dit soort projectjes...

[Anoniem: 143153]

Wat ik bij de vernieuwingen zie staan: new: stream: RC5-72 core for AMD stream video cards (#4099)

betekent dat dat we weldra toch een Ati-streamclient mogen verwelkomen op RC5-72?

[Robinski]

Anoniem: 143153 schreef op dinsdag 03 februari 2009 @ 18:36:
Wat ik bij de vernieuwingen zie staan: new: stream: RC5-72 core for AMD stream video cards (#4099)

betekent dat dat we weldra toch een Ati-streamclient mogen verwelkomen op RC5-72?

Ik vrees van niet, er zitten nogal wat stukken code in die totaal niet portable zijn (als ik zo de code en comments bekijk)
Maar wees vrij om patches in te sturen via bugs.distributed.net

[Anoniem: 143153]

moest ik kunnen code schrijven zou ik het meteen doen, maar jammer genoeg is dat eerder een 'ver van mijn bed' show

[Robinski]

Anoniem: 143153 schreef op woensdag 04 februari 2009 @ 10:14:
moest ik kunnen code schrijven zou ik het meteen doen, maar jammer genoeg is dat eerder een 'ver van mijn bed' show

Het probleem is gewoon dat er heel veel van dit soort assembler stukjes in de stream core zitten.
Het grootste probleem hiervan is, dat het vaak alleen op de CPU werkt waarvoor/waarop het geschreven is.

Helaas snap ik zelf ook niets van assembler waardoor ik het ook niet kan omzetten naar c code.
Misschien is er hier nog iemand anders die dat wel zou kunnen!?

code:

#if 0
  _asm {
    mov esi,[hi]
    mov eax,[esi]
    add eax,incr
    mov byte ptr [esi],al
    shr eax,8
    mov esi,[mid]
    mov ebx,[esi]
    mov edi,[lo]
    mov edx,[edi]
    bswap ebx
    bswap edx
    add ebx,eax
    adc edx,0
    bswap ebx
    bswap edx
    mov     [esi],ebx
    mov     [edi],edx
  }
#else
#warning PLEASE PROVIDE A PORTABLE IMPLEMENTATION
#endif

[Berke84]

Ik ben doorverwezen naar dit topic
Iemand al een GTX285 of GTX295 getest met de CUDA-cliënt? Zou graag even een beeld krijgen van wat zo'n kaartje maakt ivm de 200mil/sec van mijn 8800GTS. Worden meerder videokaarten ondersteunt door de cliënt trouwens?

[Bubbles]

Ik heb net even wat zitten testen met de GPU client op mijn bak.
GPU: 8800 GT OC
Drivers: 185.20 (PhysX: 909.01.21)
OS: Vista X64

core 0 haal ik ~302 Mkeys
core 9 haal ik ~306 Mkeys
core 10 haal ik ~279 Mkeys

core 9 geeft met alleen 100% load op 1 cpu, core 0 doet iets van 60%.
Als ik core 10 gebruik heb ik ineens vrijwel geen load.

[Robinski]

Pas wel een beetje op welke drivers je gebruikt!
Er lijken nogal wat problemen te zijn met de 180 t/m 182 drivers onder Vista64.
De client komt met een -stress niet door de test heen!

Daarnaast haal ik zelf met de 185.20 drivers, ongeveer de helft van de snelheid als ik had met de 178.24 drivers (komen beide wel door de test heen)

Dus als tip geef ik mee, probeer die eens, misschien haal je nog veel meer uit je GPU!

Wat betreft de cores... je kan beter even de beschrijving mee posten i.p.v. een nummer, daar dit niet heel duidelijk is.

Alle cores zonder aanduiding over sleep of wait hebben een (dynamische) sleep, gebaseerd op een GPU timer. De anderecores hebben een iets ander mechanismes om te wachten totdat de GPU klaar is en die gebruiken dan ook veel meer CPU.

Zelf draai ik een core zonder aanduiding, om nog een CPU client er naast te draaien op OGR!

PS
Dit alles met een 8600GT op Vista64 getest.
Normaal haal ik +/- 65 Mkey/s met de 178.24

[ Voor 5% gewijzigd door Robinski op 11-02-2009 11:40 ]

[Bubbles]

Hij kwam bij mij uitstekend door de -stress heen. Geen problemen mee ondervonden.

Teruggaan naar 178.24? Ben bang dat ik dat niet ga doen, i.v.m. betere score op F@H met nieuwere drivers, wat nog altijd mijn main project is.

Ik zal zo nog even de tests nog een keer draaien en de volledige output hier posten.

edit: hier de scores

code:

[Feb 11 11:42:50 UTC] RC5-72: using core #0 (CUDA 1-pipe 64-thd).
[Feb 11 11:43:07 UTC] RC5-72: Benchmark for core #0 (CUDA 1-pipe 64-thd)
                      0.00:00:14.25 [302,355,801 keys/sec]
[Feb 11 11:43:07 UTC] RC5-72: using core #1 (CUDA 1-pipe 128-thd).
[Feb 11 11:43:26 UTC] RC5-72: Benchmark for core #1 (CUDA 1-pipe 128-thd)
                      0.00:00:16.17 [200,349,458 keys/sec]
[Feb 11 11:43:26 UTC] RC5-72: using core #2 (CUDA 1-pipe 256-thd).
[Feb 11 11:43:45 UTC] RC5-72: Benchmark for core #2 (CUDA 1-pipe 256-thd)
                      0.00:00:16.52 [173,305,906 keys/sec]
[Feb 11 11:43:45 UTC] RC5-72: using core #3 (CUDA 2-pipe 64-thd).
[Feb 11 11:44:04 UTC] RC5-72: Benchmark for core #3 (CUDA 2-pipe 64-thd)
                      0.00:00:16.86 [204,828,745 keys/sec]
[Feb 11 11:44:04 UTC] RC5-72: using core #4 (CUDA 2-pipe 128-thd).
[Feb 11 11:44:24 UTC] RC5-72: Benchmark for core #4 (CUDA 2-pipe 128-thd)
                      0.00:00:16.23 [139,984,012 keys/sec]
[Feb 11 11:44:24 UTC] RC5-72: using core #6 (CUDA 4-pipe 64-thd).
[Feb 11 11:44:43 UTC] RC5-72: Benchmark for core #6 (CUDA 4-pipe 64-thd)
                      0.00:00:16.59 [173,023,192 keys/sec]
[Feb 11 11:44:43 UTC] RC5-72: using core #7 (CUDA 4-pipe 128-thd).
[Feb 11 11:45:02 UTC] RC5-72: Benchmark for core #7 (CUDA 4-pipe 128-thd)
                      0.00:00:16.14 [143,865,869 keys/sec]
[Feb 11 11:45:02 UTC] RC5-72: using core #9 (CUDA 1-pipe 64-thd busy wait).
[Feb 11 11:45:19 UTC] RC5-72: Benchmark for core #9 (CUDA 1-pipe 64-thd bus ...
                      0.00:00:14.22 [306,075,462 keys/sec]
[Feb 11 11:45:19 UTC] RC5-72: using core #10 (CUDA 1-pipe 64-thd sleep 100us).
[Feb 11 11:45:37 UTC] RC5-72: Benchmark for core #10 (CUDA 1-pipe 64-thd sl ...
                      0.00:00:15.44 [279,330,671 keys/sec]
[Feb 11 11:45:37 UTC] RC5-72: using core #11 (CUDA 1-pipe 64-thd sleep dyna ...
[Feb 11 11:45:54 UTC] RC5-72: Benchmark for core #11 (CUDA 1-pipe 64-thd sl ...
                      0.00:00:14.24 [302,402,836 keys/sec]
[Feb 11 11:45:54 UTC] RC5-72 benchmark summary :
                      Default core : #0 (CUDA 1-pipe 64-thd)
                      Fastest core : #9 (CUDA 1-pipe 64-thd busy wait)
[Feb 11 11:45:54 UTC] Core #9 is significantly faster than the default core.
                      Please file a bug report along with the output of
                      -cpuinfo.

en cpugebruik voor iedere core:

code:

0: 100%
1: 60%
2: 52%
3: 60%
4: 52%
6: 52%
7: 52%
9: 100%
10: ~1%
11: 100%

[ Voor 80% gewijzigd door Bubbles op 11-02-2009 12:58 ]

[SandStar]

Ikzelf heb zojuist mn configuratie gesloopt.
Met een standaard installatie had mn X process altijd een load van 50-100% als ik dnet draaide.
Met veel gekloot, diverse driver versies, xorg-x11 versies en xorg-server versies had ik het op een gegeven moment zo dat hij nauwelijks cpu gebruikte.
Helaas is dit met een laatste reboot weer ongedaan gemaakt.

Ik word redelijk gek van die nvidia drivers op linux...

Wat is trouwens het verschil tussen -bench en -stress ?
Want met -bench heeft X het behoorlijk moeilijk terwijl er met -stress nauwelijks iets gebeurd op mn cpu...

[Robinski]

De -stress is bedoeld om te kijken of er echt niks fout gaat bij de berekeningen, is iets anders dan een -bench.

Met sommige drivers blijft de client onder windows hangen (er gebeurt niets meer op CPU en GPU), dat merk je het makkelijkst met de -stress

[MadMarky]

Gaat de beta client nu alwéér te snel ermee stoppen?
Op de dnet download site staat dat ie tot 1 maart geldig zou moeten zijn. In mijn log staat echter het volgende:
[Feb 20 19:04:45 UTC] *** This BETA release expires in 6.06:17:16.00. ***
oftewel 27 februari ergens vroeg in de nacht. Rekenen is kennelijk moeilijk voor ze

[Damic]

Heb gisteren met de test build van dnetc voor ati getest en moet zeggen +460Mkeys/sec

Dit is op een HD4870 780/1000 ongeveer 9 seconden per test wu

Waar kan ik deze test build vinden: http://bugs.distributed.net/show_bug.cgi?id=4099 (win32 binary)

dnetc v2.9103-509-GTR-09012605 for Win32 (WindowsNT 5.1).
Using email address (distributed.net ID) 'removed'

[Feb 28 12:30:50 UTC] RC5-72: Loaded 00:0021E6B9:00000000:1*2^32 (12.50% done)
[Feb 28 12:30:50 UTC] RC5-72: Summary: 9 packets (9.00 stats units)
0.00:01:21.18 - [476.11 Mkeys/s]
[Feb 28 12:30:50 UTC] RC5-72: 0 packets remain in buff-in.r72
[Feb 28 12:30:50 UTC] RC5-72: 9 packets (9.00 stats units) are in
buff-out.r72
[Feb 28 12:30:50 UTC] 1 cruncher has been started.
[Feb 28 12:30:59 UTC] RC5-72: Completed 00:0021E6B9:00000000 (1.00 stats units)
0.00:00:07.84 - [479,079,530 keys/s]
[Feb 28 12:30:59 UTC] RC5-72: Loaded random 00:085615E5:00000000:1*2^32
[Feb 28 12:30:59 UTC] RC5-72: Summary: 10 packets (10.00 stats units)
0.00:01:29.03 - [476.37 Mkeys/s]
[Feb 28 12:30:59 UTC] RC5-72: 0 packets remain in buff-in.r72
[Feb 28 12:30:59 UTC] RC5-72: 10 packets (10.00 stats units) are in
buff-out.r72
[Feb 28 12:31:08 UTC] RC5-72: Completed 00:085615E5:00000000 (1.00 stats units)
0.00:00:08.90 - [482,255,482 keys/s]
[Feb 28 12:31:08 UTC] RC5-72: Loaded random 00:0E42FB10:00000000:1*2^32
[Feb 28 12:31:08 UTC] RC5-72: Summary: 11 packets (11.00 stats units)
0.00:01:37.93 - [476.91 Mkeys/s]
[Feb 28 12:31:08 UTC] RC5-72: 0 packets remain in buff-in.r72
[Feb 28 12:31:08 UTC] RC5-72: 11 packets (11.00 stats units) are in
buff-out.r72
[Feb 28 12:31:17 UTC] RC5-72: Completed 00:0E42FB10:00000000 (1.00 stats units)
0.00:00:08.89 - [483,069,095 keys/s]
[Feb 28 12:31:17 UTC] RC5-72: Loaded random 00:0237D397:00000000:1*2^32
[Feb 28 12:31:17 UTC] RC5-72: Summary: 12 packets (12.00 stats units)
0.00:01:46.82 - [477.42 Mkeys/s]
[Feb 28 12:31:17 UTC] RC5-72: 0 packets remain in buff-in.r72
[Feb 28 12:31:17 UTC] RC5-72: 12 packets (12.00 stats units) are in
buff-out.r72
[Feb 28 12:31:22 UTC] *Break* Shutting down...
[Feb 28 12:31:23 UTC] RC5-72: Saved 00:0237D397:00000000:1*2^32 (67.20% done)
0.00:00:06.09 - [473,748,704 keys/s]
[Feb 28 12:31:23 UTC] RC5-72: Summary: 12 packets (12.00 stats units)
0.00:01:46.82 - [477.42 Mkeys/s]
[Feb 28 12:31:23 UTC] RC5-72: 1 packet (1.00 stats units) is in buff-in.r72
[Feb 28 12:31:23 UTC] RC5-72: 12 packets (12.00 stats units) are in
buff-out.r72
[Feb 28 12:31:23 UTC] Shutdown complete.

Beeld bouwt wel traag op door het 100% gpu gebruik

[Robinski]

Damic schreef op zaterdag 28 februari 2009 @ 13:34:
Heb gisteren met de test build van dnetc voor ati getest en moet zeggen +460Mkeys/sec

Dit is op een HD4870 780/1000 ongeveer 9 seconden per test wu

Waar kan ik deze test build vinden: http://bugs.distributed.net/show_bug.cgi?id=4099 (win32 binary)


[...]


Beeld bouwt wel traag op door het 100% gpu gebruik

Een linux versie is wel beschikbaar, windows niet.
Ik zou eens bij dnet gaan vragen om een versie.

[d33n]

Robinski schreef op zaterdag 28 februari 2009 @ 13:56:
[...]


Een linux versie is wel beschikbaar, windows niet.
Ik zou eens bij dnet gaan vragen om een versie.

huh?.. dr is toch juist wel een win32 binary.
juist onder linux lijkt het een en ander niet goed te gaan.
Verder lees ik net dat Greg "Sir Ace" Chandler het een beetje gehad heeft met ATI/AMD op het moment, dus ik vrees dat de Stream client nog wel wat langer gaat duren..

[flying_pizza]

Marble schreef op zaterdag 28 februari 2009 @ 17:57:
[...]


huh?.. dr is toch juist wel een win32 binary.
juist onder linux lijkt het een en ander niet goed te gaan.
Verder lees ik net dat Greg "Sir Ace" Chandler het een beetje gehad heeft met ATI/AMD op het moment, dus ik vrees dat de Stream client nog wel wat langer gaat duren..

de win32 binary is er een waarmee je geen contact kunt leggen met de dnet keyservers. je doet geen "werk"dat in de stats komt. de linux client is nu als beta te downloaden van af de prerelease pagina

[d33n]

flying_pizza schreef op zaterdag 28 februari 2009 @ 18:04:
[...]


de win32 binary is er een waarmee je geen contact kunt leggen met de dnet keyservers. je doet geen "werk"dat in de stats komt. de linux client is nu als beta te downloaden van af de prerelease pagina

dat weet ik wel, maar de linux client had ik even gemist
toch even een linux bootdiscje zoeken.

[MeneerKrab]

als de client verloopt, verlopen dan ook de wu's die je aan het sparen was?

[Robinski]

MeneerKrab schreef op maandag 02 maart 2009 @ 10:19:
als de client verloopt, verlopen dan ook de wu's die je aan het sparen was?

Volgens mij (momenteel) niet, maar als dnet opeens besluit dat alle GPU clients van een bepaalde versie niet meer geteld worden, dan misschien wel.

[My]

Mijn GeForce 8600M GT doet 50Mkey/s volgens de bench. Is dit niet erg weinig?

Vervolgens rekent hij 2 uur op een WU en heeft dan nog maar 6% af...

[Robinski]

My schreef op maandag 02 maart 2009 @ 17:04:
Mijn GeForce 8600M GT doet 50Mkey/s volgens de bench. Is dit niet erg weinig?

Vervolgens rekent hij 2 uur op een WU en heeft dan nog maar 6% af...

Dat hangt er een beetje van af hoe groot je blokjes zijn.

Zelf heb ik het volgende met een 8600GT (niet M)

[Mar 02 15:57:04 UTC] RC5-72: Completed CB:FD912E59:00000000 (16.00 stats u ...
0.00:17:51.39 - [64,139,948 keys/s]
[Mar 02 15:57:04 UTC] RC5-72: Summary: 107 packets (1695.00 stats units)
1.07:12:25.08 - [64.64 Mkeys/s]

[Balachmar]

[Mar 03 10:29:17 UTC] RC5-72: Summary: 1 packet (38.00 stats units)
0.00:12:58.60 - [490.62 Mkeys/s]

Is dat wat?
GTX280 onder linux

[ Voor 7% gewijzigd door Balachmar op 03-03-2009 16:52 ]

[Anoniem: 293451]

My schreef op maandag 02 maart 2009 @ 17:04:
Mijn GeForce 8600M GT doet 50Mkey/s volgens de bench. Is dit niet erg weinig?

Vervolgens rekent hij 2 uur op een WU en heeft dan nog maar 6% af...

Ik ken dat... Soms loopt hij bij mij ook plots vast. Draait hij een tijd goed, en opeens. stilstand...

[Mar 02 20:37:52 UTC] RC5-72: Completed CC:014BF1C9:00000000 (16.00 stats units)
0.00:07:42.53 - [148,572,372 keys/s]
[Mar 02 20:37:52 UTC] RC5-72: Loaded CC:020A6770:00000000:16*2^32
[Mar 02 20:37:52 UTC] RC5-72: Summary: 80 packets (1208.00 stats units)
0.09:38:05.37 - [148.71 Mkeys/s]
[Mar 02 20:37:52 UTC] RC5-72: 5 packets (80.00 stats units) remain in
buff-in.r72
Projected ideal time to completion: 0.00:36:00.00
[Mar 02 20:37:52 UTC] RC5-72: 4 packets (58.00 stats units) are in
buff-out.r72
[Mar 02 22:11:47 UTC] *Break* Shutting down...
[Mar 02 22:11:47 UTC] RC5-72: Saved CC:020A6770:00000000:16*2^32 (62.30% done)
0.01:33:54.84 - [7,599,723 keys/s]
[Mar 02 22:11:47 UTC] RC5-72: Summary: 80 packets (1208.00 stats units)
0.09:38:05.37 - [148.71 Mkeys/s]
[Mar 02 22:11:47 UTC] RC5-72: 6 packets (96.00 stats units) are in
buff-in.r72
[Mar 02 22:11:47 UTC] RC5-72: 4 packets (58.00 stats units) are in
buff-out.r72
[Mar 02 22:11:47 UTC] Shutdown complete.

Handmatig afsluiten brengt dan keurig in beeld dat het kraten is stilgezet
Alleen het herstarten van de PC biedt dan de mogelijkheid om deze client weer aan de praat te krijgen. Gelukkig draait OGR wel verder.

[Robinski]

Anoniem: 293451 schreef op dinsdag 03 maart 2009 @ 11:48:
[...]

Ik ken dat... Soms loopt hij bij mij ook plots vast. Draait hij een tijd goed, en opeens. stilstand...

[Mar 02 20:37:52 UTC] RC5-72: Completed CC:014BF1C9:00000000 (16.00 stats units)
0.00:07:42.53 - [148,572,372 keys/s]
[Mar 02 20:37:52 UTC] RC5-72: Loaded CC:020A6770:00000000:16*2^32
[Mar 02 20:37:52 UTC] RC5-72: Summary: 80 packets (1208.00 stats units)
0.09:38:05.37 - [148.71 Mkeys/s]
[Mar 02 20:37:52 UTC] RC5-72: 5 packets (80.00 stats units) remain in
buff-in.r72
Projected ideal time to completion: 0.00:36:00.00
[Mar 02 20:37:52 UTC] RC5-72: 4 packets (58.00 stats units) are in
buff-out.r72
[Mar 02 22:11:47 UTC] *Break* Shutting down...
[Mar 02 22:11:47 UTC] RC5-72: Saved CC:020A6770:00000000:16*2^32 (62.30% done)
0.01:33:54.84 - [7,599,723 keys/s]
[Mar 02 22:11:47 UTC] RC5-72: Summary: 80 packets (1208.00 stats units)
0.09:38:05.37 - [148.71 Mkeys/s]
[Mar 02 22:11:47 UTC] RC5-72: 6 packets (96.00 stats units) are in
buff-in.r72
[Mar 02 22:11:47 UTC] RC5-72: 4 packets (58.00 stats units) are in
buff-out.r72
[Mar 02 22:11:47 UTC] Shutdown complete.

Handmatig afsluiten brengt dan keurig in beeld dat het kraten is stilgezet
Alleen het herstarten van de PC biedt dan de mogelijkheid om deze client weer aan de praat te krijgen. Gelukkig draait OGR wel verder.

Wat jij beschrijft heeft te maken met een incompatibiliteit met je drivers.

[Berke84]

Kan iemand mij bevestigen of multi-gpu setups ondersteund worden? & hoe kan je zowel de cuda-client als de normale (ogr)client naast mekaar draaien?

[SandStar]

die vraag staat volgens mij al 2 keer in dit topic... iets met multiok

[ Voor 16% gewijzigd door SandStar op 12-03-2009 18:39 ]

[Cpt00kirk]

Berke84 schreef op donderdag 12 maart 2009 @ 18:03:
Kan iemand mij bevestigen of multi-gpu setups ondersteund worden? & hoe kan je zowel de cuda-client als de normale (ogr)client naast mekaar draaien?

je maakt een snelkoppeling met het volgende achter de .exe!

**\CUDA Client\dnetc.exe" -multiok[0]

Dit zet je zowel bij de CUDA client EN de CPU client erachter.

[Berke84]

Thnx Cpt00Kirk! Works like a charm... Nu nog ff erges te weten komen of het zin heeft om SLI te gaan & ik ben weer helemaal blij

[Anoniem: 293451]

De nieuwe client (Beta 5) is gisteren vrijgegeven. Deze is zowel in Cuda 2.0 als Cuda 2.1 beschikbaar.
Het snellere kraken kan dus weer van start!

Helaas ook dit keer maar voor vier weken

[nickb90]

de gpu client ondersteunt toch geen OGR maar alleen maar RC5-72?

als dat zo is, is er dan enig idee hoelang het zal duren voordat OGR ook ondersteunt word?

[ Voor 42% gewijzigd door nickb90 op 30-03-2009 11:46 ]

[Anoniem: 293451]

De GPU-client ondersteunt inderdaad alleen RC5-72. Voor OGR-NG betekent dit geen versnelling.
De client kan wel naast de OGR-client draaien, met een minimale CPU-belasting, zodat de totale snelheid omhoog kan.
Voor het ontwikkelen van een CUDA-OGR-client zal -naar ik heb begrepen- een volledig nieuw algoritme geschreven moeten worden, omdat het OGR-algoritme zich niet leent voor het ophakken van het rekenwerk in stukjes op de manier waarop dat bij RC5-72 kan. (Zie ook eerder in deze post).

[nickb90]

oohh oke dan ga ik is even testen met de gpu client om te kijken of alles niet te warm word, hoe weet je of je cuda 2.0 of 2.1 hebt? Ik heb een Geforce 8400M

[injectie]

Vanochtend mijn ouwe graphics kaart laten hemelen. Dus heb nu Nvidia 9800GT aangeschaft. Ook maar eens de cuda client geinstalleerd gelijk.
Nu valt me op als ik de verschillende cores wil benchmarken. Dat gelijk bij de eerste Core al de melding calibration failed komt. Met het gevolg dat de benchmark stopt. Is er een manier om hier om heen te werken of wordt het alle cores handmatig benchmarken.
Heb de laatste drivers op mijn kaart. en heb gekozen voor de cuda2.1 client.

[MadMarky]

Draait de client verder wel? Het klinkt niet goed dat je al niet eens benchmarks kunt draaien...

[injectie]

De client draait met 260 Mkeys gemiddeld. Op de core die ik handmatig heb geselecteerd. Core 11
11) CUDA 1-pipe 64-thd sleep dynamic

[SandStar]

Iemand iets gehoorde over de Linux Cuda client? Ik sta er al een behoorlijke tijd op te wachten...
prutsers

[MadMarky]

Hebben jullie ook dat de client @ random zichzelf afsluit? Ik heb er al melding van gemaakt bij de d.net bugzilla pagina en ik lijk niet de enige te zijn met dit probleem. Ik gebruik de CUDA 2.0 client op een XP SP3 systeem dat ongewijzigd is sinds ik de vorige beta client heb gedraait.

[injectie]

JA dat heb ik ook MAdmarky. Ik gebruik de Cuda 2.1 Client op een XP SP3 variant. Is de eerste beta die ik draai omdat mijn nieuwe videokaart hert wel ondersteund. Dus heb geen referenties. HEb een Palit Geforce 9800GT gekocht op een AMD 64 X2 3800+ processor. CPU load van de gpu core is slechts 5%, maar als ik de 2e CPU koe aanzet wordt mijn GPU koe 40% langzamer

Dingen die ik tot nu toe constateer:
Automatische core selectie werkt niet. Dus pakt standaard core 0: CUDA 1-pipe 64-thd Dit is zo'n beetje de meest trage. Volgens de Benchmark is core 6 het snelste. 6) CUDA 4-pipe 64-thd Echter is deze zeer slecht voor de algehele performance. Tijdens surfen ed. Core (11) CUDA 1-pipe 64-thd sleep dynamics) is het beste alternatief. Een va de snelsten. Echter 60 Mkeys langzamer als core 6...... Voordeel is verder dat core 6 gemiddels na een 30 minuten al afsluit. Terwijl core 11 dit pas na ongeveer 10 uur doet.

Kun jij eventueel deze bug voor mij rapporteren? Ik weet niet precies hoe ik dat zelf kan doen.....

[injectie]

Even verder getest. Core 3 brengt het beste alternatief tussen snelheid en werkbaarheid. Nu nog kijken hoe die stabiliteit is van deze core. Core 6 valt veel uit. Core 11 amper...

Las op de Bugreport pagina dat het uitschakelen een nieuwe feature is. Getriggerd door een Error.

[injectie]

Er zijn weer nieuwe Beta's

http://distributed.net/download/prerelease.php

[x-RaY99]

Zo te zien draaien deze voor de verandering ook eens langer dan 3 weken! (48 dagen)

[maontje]

krijg hem alleeen niet werkend heb cuda 2.0 drivers installed maar client start en sluit gelijk af

[injectie]

Een vriend van me loopt ook te experimenteren met de stream client nu. Hij heeft onboard ati radeon 1250x hdmi kaart en een PCI kaart ATI radeon 2600HD Pro 512 MB.

Nu doet de stream client 50 Mkeys. Ik weet dat ie SLI niet ondersteund. maar waar kun je aanpassen welke videokaart gebruikt moet worden. OF pakt de client automatisch de PCI/e kaart?

[Evo155]

Ben bang dat ik daar geen antwoord op heb, maar ik wil nog wel een extra vraag opgooien:

Weet iemand of er voor OGR ook een GPU client komt?

[Robinski]

Evo155 schreef op woensdag 21 oktober 2009 @ 08:58:
Ben bang dat ik daar geen antwoord op heb, maar ik wil nog wel een extra vraag opgooien:

Weet iemand of er voor OGR ook een GPU client komt?

Waarschijnlijk niet, omdat OGR veel slechter draait/schaalt dan RC5 doet op een GPU client.
Uiteraard mag je zelf een core in elkaar zetten welke het wel kan, zodat deze in de client geïntegreerd kan worden.

[gp500]

Robinski schreef op woensdag 21 oktober 2009 @ 09:30:
[...]


Waarschijnlijk niet, omdat OGR veel slechter draait/schaalt dan RC5 doet op een GPU client.
Uiteraard mag je zelf een core in elkaar zetten welke het wel kan, zodat deze in de client geïntegreerd kan worden.

Dat was een reaktie 1 jaar terug van d.net

Elke core/GPU meer is toch een aanwinst.

En de GPU's worden sterker en kunnen steeds meer.
Dus OGR kan en levert wel zeker wat op.
(Heb altijd al veel meer op met het wetenschappelijke OGR, dan het cryptologische van RC5, maar dat terzijde.)

Vind D.net , ondanks dat ze het vrijwillig doen, daar wel wat makkelijk in.

[MadMarky]

Weet je het verschil tussen GPU's en CPU's en de verschillende berekeningen waar ze geschikt voor zijn? Ik zou me daar maar eens in verdiepen, het is erg goed mogelijk dat je voor OGR weinig hebt aan een GPU. het is nu eenmaal een heel andere architectuur, helemaal niet vergelijkbaar met hoe een CPU werkt.

[Evo155]

Robinski schreef op woensdag 21 oktober 2009 @ 09:30:
[...]


Waarschijnlijk niet, omdat OGR veel slechter draait/schaalt dan RC5 doet op een GPU client.
Uiteraard mag je zelf een core in elkaar zetten welke het wel kan, zodat deze in de client geïntegreerd kan worden.

Daar ben ik helaas niet toe in staat. Wbt dat verschil tussen CPU en GPU: ik heb me laten vertellen dat een GPU veel minder nauwkeurig rekent dan een CPU. Klopt dat ongeveer?

[Qwerty-273]

Wat ik me van een discussie herinner is dat de huidge berekeningng manier voor OGR behoorlijk wat data in zijn cache nodig heeft om berekeningen te kunnen doen. En dat deze data niet in de beschikbare cache per core van een GPU van destijds zou passen. En dat men eigenlijk niet direct een ontwikkelaar heeft die dit op wilt pakken - je zou dan namelijk een andere manier moeten bedenken om de berekeningen voor elkaar te krijgen.
Grootste punt namelijk met d.net is dat veel van de core ontwikkelaars het er bij doen als hobby waardoor bij een privesituatie je hoofd ontwikkelaar van een bepaalde core wegvalt.
Je zit dan namelijk met twee categorien:
- core ontwikkelaar die een stuk code bedenkt waarmee je RC5 of OGR kunt berekenen
- core ontwikkelaar die het bovenstaande stuk code africht op een bepaalde hardware architectuur en eventuele optimalisaties aanbrengt.

[Evo155]

Das een duidelijk verhaal. Thanx!

[gp500]

@ madmark: tuurlijk kan OGr slecht eruit komen.
Maar daarom kan OGr voroal met de nieuwere GPU's wel steeds beter kunnen werken.

En zoals Qwerty zegt mss meer een cache geval en RC5 zal makkelijk zijn om dat eerst te voltooien (al lijkt dat ook erg sloom te gaan),

Nvidia maakte kenbaar dat bij hun nieuwe kaart meer rekening is gehouden met Cuda en dat de cache (soort L1 of L2 denk ik ) vergroot was.
Weet niet welke GPU dat was, stond op T.net IMO.

[martinx76]

Yippie, het werkt. Dankzij alle tips in dit topic heb ik nu 2 clients werkende.
Maar de GPU client draait maar met 40 Mkeys/sec. Valt me nogal tegen.

Is hier nog een tip voor?

Specs:
WinXP Home SP2
Intel E2220 Dual @2.4 Ghz
Nvidia Gforce 9500 GT, driver 180.20

[x-RaY99]

Een snellere videokaart? De 9500GT blinkt niet direct uit in CUDA snelheden.
De 9800GTX bijv. heeft in plaats van 32 cuda cores 128 cuda cores en doet ongeveer 200Mkeys/sec.

Als je echt gek wilt doen, een Radeon 5870 doet ruim 1000Mkeys/sec.

[martinx76]

chips, dat had ik eerder moeten weten. Mijn vorige kaart was aan het overlijden dus er zit net een nieuwe in..... beetje jammer

[Anoniem: 321707]

aardige site voor GPU benchmarks: http://service.futuremark.com/hardware
alhoewel dat meer interessant is voor gamers, cuda is toch iets anders

Edit: info over GPU en BOINC:
http://boincfaq.mundayweb...x.php?language=1&view=471

Edit2: over stream processors:
http://www.nvidia.co.uk/o...ics_cards_buy_now_uk.html
http://www.amd.com/us/pro...s/ati-radeon-hd-5000.aspx
bij de "specifications" staan # of stream processors vermeld

ATI laat Nvidia ruim acher zich, jammer dat er slechts 2 BOINC-projecten zijn die CAL ondersteunen

[ Voor 67% gewijzigd door Anoniem: 321707 op 10-03-2010 14:34 ]

[Anoniem: 321707]

Okay zelf ook een miskleun gemaakt:
Ik heb de HD-5770 gekocht en dacht na de stampede Milkyway@Home eens onveilig te gaan maken.
Deze ATI-kaart ondersteunt echter geen double precision
http://milkyway.cs.rpi.ed..._thread.php?id=1505#35846

Blijft er Collatz over (1 WU wordt gecrunched in 11,5 min +/-) of wellicht F@H (niet BOINC)
Misschien aardig idee om een sticky te maken hier in /5 met algemene info over de GPU-mogelijkheden bij de diverse projecten.

Edit: Ik ga zelf wat tijd investeren om een mooie FAQ hiervoor te schrijven als dat gewenst is.

[ Voor 9% gewijzigd door Anoniem: 321707 op 12-03-2010 20:48 ]

[HeepH]

ati's streamprocessors zijn wel minder krachtig dan die van nvidia, dat weet je neem ik aan, iconized?

(ik heb overigens niet naar benchmarks gekeken, dus als ze in de benchmarks nvidia ook voor blijven dan klopt wat je zegt natuurlijk)

[Damic]

x-RaY99 schreef op woensdag 10 maart 2010 @ 11:46:...
Als je echt gek wilt doen, een Radeon 5870 doet ruim 1000Mkeys/sec.

correctie +1.5Gkeys/sec de 5770 doet er al 900Mkeys/sec

[The_Greater]

Damic schreef op zondag 23 mei 2010 @ 07:44:
[...]
correctie +1.5Gkeys/sec de 5770 doet er al 900Mkeys/sec

Even voor jullie getest op de ATI5870
0.00:01:40.62 - [1,437,288,904 keys/s]

[Damic]

ne minuut 40? Je pakjes zijn 100*2^32 zeker?

[The_Greater]

Damic schreef op zondag 23 mei 2010 @ 19:12:
ne minuut 40? Je pakjes zijn 100*2^32 zeker?

Geen idee eigenlijk, zal ff kijken...

code:

[May 23 13:35:23 UTC] RC5-72: Loaded CC:BBF9BC40:00000000:64*2^32
[May 23 13:35:23 UTC] RC5-72: Summary: 106 packets (1867.00 stats units)
                      0.01:21:22.76 - [1,612.63 Mkeys/s]
[May 23 13:35:23 UTC] RC5-72: 0 packets remain in buff-in.r72
[May 23 13:35:23 UTC] RC5-72: 1 packet (64.00 stats units) is in
                      buff-out.r72
[May 23 13:35:23 UTC] The perproxy says: "[DPC]The_Greater - Grazing for
                      World Peace!"

[Jejking]

Mag ik trouwens ff vragen wat DNETC precies inhoudt? Ik ben al een aantal FAQ's doorgeweest maar mijn grijze massa is de draad al kwijt na het woordje wrapper

DNETC@Home is a wrapper between BOINC and distributed.net.

[SandStar]

zelfde als yoyo: een boinc implementatie van de distributed.net client.

Je punten komen niet bij DPC terecht maar bij het DNETC@Home team

[Qwerty-273]

dnetc - is de naam van de client van Distributed.net. Het staat dan ook heel origineel voor Distributed.net client.
DNETC@Home is een oplossing om met je BOINC client ook gebruik te maken van deze d.net client zonder dat je daarvoor zelf een aparte client moet installeren en beheren (updates etc.). Daarnaast boort het ook een nieuwe groep distributed computers aan - die groep die fan zijn van Boinc en dan van project tot project wisselen die op dat platform draaien.

[Cpt00kirk]

volgens mij is het zelfs mogelijk om de client van DCNET@HOME te pakken en met dirty skillz de naam van hun aan te passen en naar een naam te veranderen zodat hij bij DPC wordt geteld. Zit op het werk dus pin met er niet op vast, zal even weer gaan zoeken waar ik het vond.

The_Greater schreef op zondag 23 mei 2010 @ 14:08:
[...]

Even voor jullie getest op de ATI5870
0.00:01:40.62 - [1,437,288,904 keys/s]

Factory overclocked gaan ze zelfs harder en tikken ze net de 2.0 miljoen niet aan. Heb een Club3D OC 5870

[Jejking]

Qwerty-273 schreef op woensdag 09 juni 2010 @ 16:41:
dnetc - is de naam van de client van Distributed.net. Het staat dan ook heel origineel voor Distributed.net client.
DNETC@Home is een oplossing om met je BOINC client ook gebruik te maken van deze d.net client zonder dat je daarvoor zelf een aparte client moet installeren en beheren (updates etc.). Daarnaast boort het ook een nieuwe groep distributed computers aan - die groep die fan zijn van Boinc en dan van project tot project wisselen die op dat platform draaien.

Ah, daar stond wrapper dus voor. Ik snap 'm weer.

Dus met de GPU-client ben je bezig met OGR en RC5 om allerlei zware encryptiechallenges te kraken als ik 't goed begrijp. Hmm, gelukkig weet ik nog een nieuwsbericht met een mededeling dat videokaarten erg snel waren met number crunching. Es kijken

Cpt00kirk schreef op woensdag 09 juni 2010 @ 17:08:
volgens mij is het zelfs mogelijk om de client van DCNET@HOME te pakken en met dirty skillz de naam van hun aan te passen en naar een naam te veranderen zodat hij bij DPC wordt geteld. Zit op het werk dus pin met er niet op vast, zal even weer gaan zoeken waar ik het vond.

Maar... maar... wat is het nut daarvan? Kan je beter een geïntegreerde oplossing nemen als BOINC, veel makkelijker toch? En volgens mij is er al een DPC-team, daar ga ik ff naar zoeken.

[Jejking]

Ik ga hier nog maar een technische vraag neerzetten want ik kom een vaag verschijnsel tegen bij het gebruik van DNETC via BOINC, in vergelijking met Collatz Conjecture op de GPU.

- De HD5770 wordt met DNETC zo'n 14 graden warmer dan met CC.
+ Alles wat ik tussendoor doe op het gebied van video/gaming, gaat vloeiend. Met CC hoefde ik dat niet in m'n hoofd te halen, een YouTube'je op 360p/480p ging tot op zekere hoogte nog wel maar HD en gewone films kon ik wel direct vergeten. Nu niet? Alles werkt perfect. Nou ja, games niet geheel maar in ieder geval beter dan met CC aan. Gevalletje voor games de graka nog steeds op pauze zetten.
= GPU load is op beide projecten hetzelfde, 98-99%.

Om eerlijk te zijn snap ik niet wat de verschillen in temperatuur en handling veroorzaakt. Heeft iemand hier een idee van

[ Voor 8% gewijzigd door Jejking op 10-06-2010 13:57 ]

[Anoniem: 321707]

De CC GPU applicatie voert voornamelijk integer bewerkingen uit, dit is een lage belasting voor de GPU, slechts een klein gedeelte van de totale hoeveelheid transistoren op de GPU chip wordt gebruikt.
Toch is de belasting tegen de 100% want de sub chipset voor integer bewerkingen kan dit niet sneller uitvoeren.
De GPU is eigenlijk ontworpen voor veel complexere 3D bewerkingen (voornamelijk floating point berekeningen).
Ik neem aan dat de Dnet GPU applicatie veel meer floating point bewerkingen genereerd.

De verschillen in de performance penalty kan ik zo één-twee niet verklaren wellicht is de Dnet applicatie netter geprogrammeerd zodat het resources teruggeeft aan het systeem als de gebruiker dat nodig heeft.

[Jejking]

Hmm, goeie uitleg. Even kijken of de rest van het net er nog iets over te zeggen heeft.

[SandStar]

Jejking schreef op woensdag 09 juni 2010 @ 17:55:
[...]

Ah, daar stond wrapper dus voor. Ik snap 'm weer.

Dus met de GPU-client ben je bezig met OGR en RC5 om allerlei zware encryptiechallenges te kraken als ik 't goed begrijp. Hmm, gelukkig weet ik nog een nieuwsbericht met een mededeling dat videokaarten erg snel waren met number crunching. Es kijken

[...]

Maar... maar... wat is het nut daarvan? Kan je beter een geïntegreerde oplossing nemen als BOINC, veel makkelijker toch? En volgens mij is er al een DPC-team, daar ga ik ff naar zoeken.

Als je de boinc client gebruikt en niks aanpast ben je niet voor DPC bezig maar voor het "DNETC@HOME" team. Die ons trouwens dik aan het inhalen zijn.

Dus eigelijk is het aan te raden de distributed.net client te gebruiken en je bij het DPC team aan te melden.

[Jejking]

Er is een DPC-team binnen de BOINC-DNETC-versie? Zit ik nu ook netjes bij.

[SandStar]

Jejking schreef op donderdag 10 juni 2010 @ 23:41:
Er is een DPC-team binnen de BOINC-DNETC-versie? Zit ik nu ook netjes bij.

*zucht*

Het "DNETC@HOME" team op RC5.
http://stats.distributed....p?project_id=8&team=31955

Jouw id:
http://stats.distributed....hp?project_id=8&id=475402

En jouw plek binnen het "DNETC@HOME" team
http://stats.distributed....ource=o&low=601&limit=100

Dat het "DNETC@HOME" team ook zelf stats maakt met subteams doet geen afbreuk aan het feit dat je niet voor DPC bezig bent.

[Jejking]

Duidelijk, maar ik heb geen trek in externe clients, wil gewoon het beheer in m'n BOINC Manager hebben. Dus als er een manier is om via BOINC de punten neer te zetten bij DPC dan wil ik het doen en anders is het pech gehad.

[ Voor 4% gewijzigd door Jejking op 11-06-2010 12:30 ]

[SandStar]

Daar weet Cpt00kirk wellicht wat van.

Zelf zou ik als eerste op zoek gaan naar een "dnetc.ini" file en daar je email adres aanpassen en kijken of die setting vervolgens behouden blijft.

[Jejking]

Niet gevonden. Ook niks soortgelijks. Hmm, ff verder kijken.

[Proxy]

Op de Pre-releasepagina staan inmiddels een CUDA 3.1-client voor Windows en CUDA 3.0-client voor Mac OS X.

[Xaverius]

Het heeft vast hier mee te maken.

It has come to our attention that a problem exists with some of the nVidia CUDA systems running on the Windows operating system. The CUDA system already released is up to version 3.1, while our dnetc application only supports up to CUDA 2.2.

If your graphics driver is designed for a higher version than this, the application will appear to run normally, but will send us junk results. One way to test if you are running a compatible version is to run ‘dnetc -test’. A working system should pass all of the tests.

When dnetc for CUDA systems loads, it shows a line that begins:- ‘nvcuda.dll Version:’. If the version displayed is 8.17.11.9775, your card will produce junk data (which our stats system will filter).

We hope to release a new version of the dnetc application that will support the CUDA 3.1 drivers soon.

We thank you for your continued support.

Moo!

[Proxy]

Xaverius schreef op zondag 04 juli 2010 @ 06:24:
Het heeft vast hier mee te maken.

[...]

Yep, deze pre-release loopt succesvol door de 32 tests heen iig, i.c.m. 258.69.

[joh14vers6]

Vreemd, met driver v257.21 maakt het bij mij niet uit of ik de released client of de release candidate client gebruik. Bij beide zijn alle 32 testen OK. Ivm mogelijke blokkering van resultaten heb ik toch maar de RC draaien. Ik denk dat probleem ook kaart afhankelijk is. Ik heb nu een inmiddels oudere 8800GT kaart in gebruik.

[Jejking]

Overigens, stél dat ik van de BOINC-client naar de echte DNETC-client switch, verhuizen al m'n punten dan alsnog naar DPC als ik me bij het team aansluit? Meende van wel.

[SandStar]

Jejking schreef op maandag 05 juli 2010 @ 18:10:
Overigens, stél dat ik van de BOINC-client naar de echte DNETC-client switch, verhuizen al m'n punten dan alsnog naar DPC als ik me bij het team aansluit? Meende van wel.

nee

[Jejking]

Crap.

[SandStar]

Jejking schreef op maandag 05 juli 2010 @ 21:33:
Crap.

tsja, tis niet dat we je niet gewaarschuwd hadden voor die client...

[Jejking]

Maakte hier iemand nu gebruik van die externe client? Ik zit aan te rommelen met de settings maar zie nergens iets staan waarbij ik bij een team kan joinen

Logo is wel een overigens, weet niet of dat een teken is dat ik goed zit

Edit: gatverdamme... GPU-usage van 20%... nu pas lijkt het ergens op, volgas.

[ Voor 14% gewijzigd door Jejking op 26-07-2010 20:24 ]

[d33n]

Jejking schreef op maandag 26 juli 2010 @ 20:15:
Maakte hier iemand nu gebruik van die externe client? Ik zit aan te rommelen met de settings maar zie nergens iets staan waarbij ik bij een team kan joinen

Logo is wel een overigens, weet niet of dat een teken is dat ik goed zit

Edit: gatverdamme... GPU-usage van 20%... nu pas lijkt het ergens op, volgas.

Externe client? Je bedoelt de dnetc client van distributed.net? dat is de enige echte... wat dat betreft kun je beter de BOINC-wrapper zien als externe client. check anders de wiki even, dan moet je er wel uit kunnen komen. http://wiki.dutchpowercows.org/index.php/RC5-72 en http://wiki.dutchpowercows.org/index.php/Distributed.net

[ Voor 7% gewijzigd door d33n op 26-07-2010 20:28 ]

[Jejking]

Ik bedoel inderdaad de DNETC-client van Distributed.net (wat een fucking zoektocht )... Daar heb ik nu wat aanloopprobleempjes mee. Boinc is zo verschrikkelijk veel makkelijker te hanteren.

Edit: heel handig om mezelf goed aan te melden. Hulde, ben het aan het fixen

Edit: ik denk dat ik van de externe client af wil, GPU usage is veel te grillig om er iets goeds mee te doen.

[ Voor 33% gewijzigd door Jejking op 26-07-2010 20:34 ]

[d33n]

Jejking schreef op maandag 26 juli 2010 @ 20:29:
Ik bedoel inderdaad de DNETC-client van Distributed.net (wat een fucking zoektocht )... Daar heb ik nu wat aanloopprobleempjes mee. Boinc is zo verschrikkelijk veel makkelijker te hanteren.

D.net is dan ook al wat langer bezig dan boinc en de client is eigenlijk juist veel hanteerbaarder. je hebt een dnetc.exe en een dnetc.ini (die wordt aangemaakt nadat je de eerste keer heb gestart en je instellingen op hebt gegeven) in de dnetc.ini staan je instellingen, deze kun je veranderen via notepad, of je kunt gewoon via de client de instellingen veranderen. Het belangrijkste is dat je e-mail adres goed is

[Jejking]

Dat laatste is inmiddels rechtgetrokken.

Ik wacht toch nog even op m'n wachtwoord per mail, dan kan ik daarna meteen op de échte júiste manier in het DPC-team springen zonder met die rotte client te hoeven werken. Gefixt toch?

[Jejking]

Ligt alles plat ofzo?

Dnetc.net:

It works!

This is the default web page for this server.

The web server software is running but no content has been added, yet.

Héél vaag. En ik wilde nog net ff wat pakketjes droppen

[flying_pizza]

zou is gaan kijken op www.distributed.net, die werkt wel

[SandStar]

Jejking schreef op zaterdag 28 augustus 2010 @ 11:11:
Ligt alles plat ofzo?

Dnetc.net:

[...]

Héél vaag. En ik wilde nog net ff wat pakketjes droppen

Het is je toch al eens eerder gezegd: dnetc.net is niet distributed.net.

[Xaverius]

Inderdaad is dnet.net geen distributed.net! De BOINC-client die dnet heet heeft niks te maken met distributed.net. En de punten die je daarbij scoort help je me om de Dutch Power Cows verder van de eerste plaats bij RC5-72 weg te houden bij distributed.net.

Nog een hele goede reden om gewoon de originele distributed.net-client te gebruiken!

[Jejking]

SandStar schreef op zaterdag 28 augustus 2010 @ 12:38:
[...]


Het is je toch al eens eerder gezegd: dnetc.net is niet distributed.net.

Jij je zin.

Xaverius schreef op zaterdag 28 augustus 2010 @ 14:16:
Inderdaad is dnet.net geen distributed.net! De BOINC-client die dnet heet heeft niks te maken met distributed.net. En de punten die je daarbij scoort help je me om de Dutch Power Cows verder van de eerste plaats bij RC5-72 weg te houden bij distributed.net.

Nog een hele goede reden om gewoon de originele distributed.net-client te gebruiken!

Waarbij ik geen progress zie en m'n videokaart niet 100% belast wordt maar voor 30 oid en wat al niet meer. Helaas is dat geen optie dus!

[Xaverius]

Het heeft helemaal niks te maken met ons zin krijgen, dnetc@home is een totaal ander project dan distributed.net. Ja, ze doen allebei hetzelfde werk waarbij dnetc@home ons (DPC) van de eerste plaats heeft gestoten in de officiële stats... Maar....

[list]• dnetc@home gebruikt een eigen client (een wrapper om de distributed.net-client in/onder BOINC)• dnetc@home gebruikt hierdoor een eigen server om het werk te distribueren

Ja, de twee projecten doen het zelfde werk, maar....
Nee, het zijn echt twee totaal verschillende projecten met eigen servers.

De distributed.net servers doen het gewoon, ik heb geen ervaring met de RC5-72 GPU client maar heb je al eens in het RC5-72 topic een vraag gesteld over het maar 30% gebruiken van de GPU van de officiële client. Ik heb er geen apart topic in ieder geval voor zien langskomen, dat zou ik me wel herinneren.

Dus bij vragen/opmerkingen over dnetc.net is het handiger om daar een eigen topic over te maken zoals in dit geval ook aan de hand is.

offtopic:
Als je dit apart vindt, ga dan eens kijken wat er bij die wiskundige projecten allemaal aan verschillende projecten zijn die hetzelfde werk doen...

[SandStar]

Jejking schreef op maandag 30 augustus 2010 @ 00:02:
[...]

Jij je zin.

[...]

Waarbij ik geen progress zie en m'n videokaart niet 100% belast wordt maar voor 30 oid en wat al niet meer. Helaas is dat geen optie dus!

Je moet wel de juiste core selecteren

[ColdFusion]

Om de GPU voor de volle 100%te laten draaien, moet je op je CPU 1 core vrijhouden is mijn ervaring (nu 1 dag). Op mijn quadcore nu 3 cores aan het werk, de 4e is vrij en de GPU pakt nu de volle 100%. Zet ik de 4 cores aan het werk, zakt de GPU in.

Om de voortgang te kunnen zien, dit in je dnetc.ini zetten (kan met kladblok):

code:

[display]
detached=no
progress-indicator=auto-sense
hed=no

[ Voor 24% gewijzigd door ColdFusion op 30-08-2010 12:11 ]

[bobsnl]

Ik draai de x32 client voor OGR en de CUDA 3.1 beta voor RC5-72. Voor mij maakt het niets uit of ik nu de CPU client van 4 naar 3 cores zet, of zelfs uit zet. De CUDA-client blijft 135 Mkeys/s geven.
Doe ik iets fout of is die waarde normaal voor een GTX260-216?