Hi mein Client läuft nicht mehr.
Gibts schon nen ersatzclient?oder anderweitige abhilfe?Will wieder crunchen.
Mfg
LTZ 400
Ja, der Cuda-Client beendet seine Arbeit offenbar pünktlich --> http://www.iq-hardware.de/forum/viewtopic.php?t=2529&postdays=0&postorder=asc&start=200 (http://www.iq-hardware.de/forum/viewtopic.php?t=2529&postdays=0&postorder=asc&start=200) (siehe Beiträge ab 19.1.2009). Da hilft wohl vorläufig nur, auf die altbekannten "Alternativen" auszuweichen.
Hmm
Dann warte ich halt bis der neue kommt
Zitat von: Noreia am 22. Januar 2009, 11:58:30 Uhr
Dann warte ich halt bis der neue kommt
Der neu Cuda-Client ist raus: v2.9103.509 (beta)
http://www.distributed.net/download/prerelease.php (http://www.distributed.net/download/prerelease.php)
Der neue Beta rechnet auch nur 28 Tage.
Zitat von: tyco am 26. Januar 2009, 07:45:30 Uhr
Der neu Cuda-Client ist raus: v2.9103.509 (beta)
Mist.
Hatte ich doch die (klitzekleine) Hoffnung dass der Spuk jetzt ein Ende hat.
Ich hasse den Cuda... :heul: :traurig2:
Ich auch so lange ich ne ATI hab ;D
Zitat von: tyco am 26. Januar 2009, 07:45:30 Uhr
Der neu Cuda-Client ist raus: v2.9103.509 (beta)
Prima, pünktlich zur Fertigstellung meines "neuen" Spielzeugs... ;D Die nächsten 28d gibts also ein paar mehr WU/d.
supi 652 wus gerechnet, 51 wurden gezählt mit dem neuen beta clint. Bei mir steht 5 Tage remaining -.-
Zitat von: Burn.Proof am 27. Januar 2009, 18:13:30 Uhr
supi 652 wus gerechnet, 51 wurden gezählt mit dem neuen beta clint. Bei mir steht 5 Tage remaining -.-
Da scheint was schief gelaufen zu sein. Oder hast du so spät geflusht? Sonst lösche mal die buff-in.r72. Bei mir wurde alles gewertet...sogar mehr...von vorgestern eben...da fehlten ein paar.
Mit 5 Tagen passt wohl. Die haben den Client wieder mal so spät veröffentlicht.
Zitat von: NEMESIS am 26. Januar 2009, 16:34:09 Uhr
Ich hasse den Cuda... :heul: :traurig2:
Ich auch >:(
Ich mag ihn :) und hab ihn gerade wieder aktiviert >:D
Habs nochmal Probiert. Den Clint neu eingerichtet und diesmal größere Wus direkt von dnet geholt. Wieder das gleiche. Wurden nur etwa 50 WUs angerechnet, obwohl ein Paket ja schon 64 Wus hat. Ich hab 2 gerechnet. Keine ahnung was da los ist. Aber an mir kann es kaum liegen. Mit welchem Core rechnet ihr? Ich glaub Core 7 4x64 thd.
ngdfjhngodfgjkhdfjhnijgfiöjgfklghrphjoiftihhjjgtklhjföthjtfjiohjgfhl
Meine 8800GT rechnet mit core #6 (CUDA 4-pipe 64-thd).
Die Ursache könnte an den großen WUs liegen. Die sind noch neu. Ich kenne niemanden der das schon getestet hat mit den großen WUs.
Edit: Seelenkrank und WilliamTC fehlen auch tausende von WUs und bei einem gewissen Greg Childers sind von 50.000 WUs nur 3.000 gewertet worden.
http://www.iq-hardware.de/forum/viewtopic.php?t=2309&start=160 (http://www.iq-hardware.de/forum/viewtopic.php?t=2309&start=160)
oh ja core 6 isses. Am ersten Tag hab ich noch kleine WUs gerechnet und da fehlten ja auch 600. Ich Rechne nommal 100 kleine ... mal schaun. Aber unnötig Strom verbrauchen ohne dasses angerechnet wird, bringt ja auch nix.
Hi
Also ich rechne ganz normale Wus und mir fehlt nix weder mit dem alten Client noch jetzt mit dem neuen.Ich rechne auch mit Core 6.
Hmm wieder nur 74 von 109 gewertet. Keine Ahnung woran das liegt. Fetche ganz normal WUs vom Team Proxy und wieder zurück. Komische sache. :/
Es hat einen Bug in den neuen Proxies gegeben. Einmal wurden ungültige Blocks verschickt und zum anderen wurden die neuen großen Blocks als nur eine WU gewertet.
http://n0cgi.distributed.net/cgi/dnet-finger.cgi?user=mikereed (http://n0cgi.distributed.net/cgi/dnet-finger.cgi?user=mikereed)
Vielleicht ist das die Ursache deines Problems gewesen. Ich hoffe das Problem ist nun gelöst. Die buff-in solltest du vorsichtshalber besser löschen.
Rechtzeitig bevor sich der bisherige CUDA-Client morgen verabschiedet, gibt es einen neuen Prerelease Client.
[x86/CUDA] v2.9103.509 (beta2) 2009-02-01 (http://www.distributed.net/download/prerelease.php)
Diesmal hat er noch eine echte Laufzeit von 25 Tagen.
Zitieren[Feb 01 09:55:43 UTC] RC5-72: 1 packet (1.00 stats units) is in buff-out.r72
[Feb 01 09:55:50 UTC] RC5-72: using core #0 (CUDA 1-pipe 64-thd).
[Feb 01 09:56:07 UTC] RC5-72: Benchmark for core #0 (CUDA 1-pipe 64-thd)
0.00:00:14.12 [312,023,801 keys/sec]
[Feb 01 09:56:07 UTC] RC5-72: using core #1 (CUDA 1-pipe 128-thd).
[Feb 01 09:56:24 UTC] RC5-72: Benchmark for core #1 (CUDA 1-pipe 128-thd)
0.00:00:14.01 [313,402,294 keys/sec]
[Feb 01 09:56:24 UTC] RC5-72: using core #2 (CUDA 1-pipe 256-thd).
[Feb 01 09:56:41 UTC] RC5-72: Benchmark for core #2 (CUDA 1-pipe 256-thd)
0.00:00:14.31 [307,782,216 keys/sec]
[Feb 01 09:56:41 UTC] RC5-72: using core #3 (CUDA 2-pipe 64-thd).
[Feb 01 09:56:57 UTC] RC5-72: Benchmark for core #3 (CUDA 2-pipe 64-thd)
0.00:00:13.82 [318,160,935 keys/sec]
[Feb 01 09:56:57 UTC] RC5-72: using core #4 (CUDA 2-pipe 128-thd).
[Feb 01 09:57:16 UTC] RC5-72: Benchmark for core #4 (CUDA 2-pipe 128-thd)
0.00:00:16.45 [263,589,776 keys/sec]
[Feb 01 09:57:17 UTC] RC5-72: using core #6 (CUDA 4-pipe 64-thd).
[Feb 01 09:57:33 UTC] RC5-72: Benchmark for core #6 (CUDA 4-pipe 64-thd)
0.00:00:13.78 [318,374,126 keys/sec]
[Feb 01 09:57:33 UTC] RC5-72: using core #7 (CUDA 4-pipe 128-thd).
[Feb 01 09:57:52 UTC] RC5-72: Benchmark for core #7 (CUDA 4-pipe 128-thd)
0.00:00:16.34 [268,422,912 keys/sec]
[Feb 01 09:57:52 UTC] RC5-72: using core #9 (CUDA 1-pipe 64-thd busy wait).
[Feb 01 09:58:09 UTC] RC5-72: Benchmark for core #9 (CUDA 1-pipe 64-thd busy wait)
0.00:00:14.01 [311,399,200 keys/sec]
[Feb 01 09:58:09 UTC] RC5-72: using core #10 (CUDA 1-pipe 64-thd sleep 100us).
[Feb 01 09:58:29 UTC] RC5-72: Benchmark for core #10 (CUDA 1-pipe 64-thd sleep 100us)
0.00:00:16.48 [266,128,381 keys/sec]
[Feb 01 09:58:29 UTC] RC5-72: using core #11 (CUDA 1-pipe 64-thd sleep dynamic).
[Feb 01 09:58:47 UTC] RC5-72: Benchmark for core #11 (CUDA 1-pipe 64-thd sleep dynamic)
0.00:00:16.28 [271,124,028 keys/sec]
[Feb 01 09:58:47 UTC] RC5-72 benchmark summary :
Default core : #0 (CUDA 1-pipe 64-thd)
Fastest core : #6 (CUDA 4-pipe 64-thd)
[Feb 01 09:58:47 UTC] Core #6 is significantly faster than the default core.
Please file a bug report along with the output of
-cpuinfo.
Zwei subjeltive Eindrücke hab ich bisher vom Client:
- er ist langsamer als sein Vorgänger
- es lässt sich nebenbei wesentlich flüssiger arbeiten
Erkauft man sich zweiteres mit ersterem? Kann das jemand objektiv bestätigen?
Ok, dann probier ichs heut abend noch mal. Wenn man große WUs rechnet hat man auf jedenfall ne höhere rate. Bei mir ist die von ungefähr 300Mkeys auf 315 gestiegen. Wenn jetzt alle Kinderkrankheiten mal ausgemerzt sind, lohnt sich die sache auch.
Ich finde den Core#6 am schnellsten, aber er blockiert auch am meisten.
Ciao
O ha, endlich funktionierts. 105 gerechnet in großen packeten und 105 angerechnet. Es geschehen noch Wunder.
Wie geht das mit den großen Blöcken? einfach nur den aktuellen beta-proxy oder muß man da noch was einstellen?
Ciao
jow, halt nen proxy eintragen der die großen wus unterstützt und preferred-blocksize=0 oder halt auf die größe die du willst.
Was is mit dem Team Proxy? Der kann die noch nicht oder ?
Zitat von: Burn.Proof am 05. Februar 2009, 20:01:19 Uhr
Was is mit dem Team Proxy? Der kann die noch nicht oder ?
Nö! Der HWE-Teamproxy flusht ja auch noch über den GHN-Proxy....der müsste dann ja auch die großen Pakete verschicken und einsammeln können.
Habe es eben mal mit den großen Paketen versucht. Aufgefallen ist mir lediglich das die grafische Darstellung in der Option "Core Throughput" ziemlich konstant ist gegenüber den einzelnen WUs. Eine echte Output-Steigerung ist mir bei dem kleinen Test aber nicht aufgefallen.
Der Clint berchnet ja die tazächliche Rate. Die ist bei mir gestiegen. Wird bei Core Throughput in dem Feld Summary/Rate angezeigt.
Zitat von: Burn.Proof am 06. Februar 2009, 10:10:48 Uhr
Der Clint berchnet ja die tatsächliche Rate. Die ist bei mir gestiegen. Wird bei Core Throughput in dem Feld Summary/Rate angezeigt.
Um wie viel?
Also bei mir macht das ca. knapp +2% aus. Von ~311 Mkeys/s auf ~ 317 Mkeys/s.
Bei mir isses von 300 auf 317 hoch. Lohnt also schon
Zitat von: tyco am 05. Februar 2009, 21:32:41 Uhr
Nö! Der HWE-Teamproxy flusht ja auch noch über den GHN-Proxy....der müsste dann ja auch die großen Pakete verschicken und einsammeln können.
Hatte die Tage beim Testlauf mit ein paar großen WUs, direkt bei Distri gezogen, über den perProxy ausversehen die letzte große WU über den TP geschickt.
Der TP-Proxy hat die WU (iter 16) zwar klaglos akzeptiert, zählte aber dafür nur eine WU.
Ist nun nicht wirklich verwunderlich, aber theoretisch kann man seine WUs auch über ältere Versionen flushen, die Auswertung erfolgt dann wieder korrekt bei Distri.
Allet noch suboptimal.
Auf Dauer und nach Ende der Betaphase des Proxy sollten wir/werde ich Franco bzw. Andreas (Gudi) bitten die notwendigen Änderungen am TP vorzunehmen.
Die Anpassungen betrifft ja nicht nur den Proxy und die Auswertung der WUs, sondern auch die neuen Hardwareplattformen (CUDA, PS3) in den Stats zu integrieren.
Noch 'ne Frage zu den client/proxy-Einstellungen:
Im client hatte ich preferred-blocksize=8 eingestellt, gezogen wurde aber eine Blockgröße von 16. Oberhalb von iter16 funzt alles bestens. Erklärung?
Zudem ist mir im PerProxy nicht klar wie die "maxkeysdone" behandelt wird. Denn die Einstellung lag beim Test bei 10, so wurde jede WU einzeln gen Distri geflusht.
MM nach wird ein großer Block nicht als
einzelner Block im Proxy gezählt, sondern nach "Inhalt" (iter 16/32/xx). Demnach müßte man die maxkeysdone mit der Blockgröße multiplizieren?
Richtig?
Oder bin ich flasch gewickelt. ;D