28. März 2024, 20:34:01 Uhr


Antworten

Achtung: Dieser Beitrag wird erst angezeigt, wenn er von einem Moderator genehmigt wurde.
Anhänge und andere Optionen
Verifizierung:
Bitte lassen Sie dieses Feld leer:
Geben Sie die Buchstaben aus dem Bild ein
Buchstaben anhören / Neues Bild laden

Geben Sie die Buchstaben aus dem Bild ein:

Wo findet das Oktoberfest statt?:
Tastenkürzel: Alt+S Beitrag schreiben oder Alt+P für Vorschau

Zusammenfassung

Autor LiLaLux
 - 13. Februar 2009, 20:00:41 Uhr
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
Autor Burn.Proof
 - 13. Februar 2009, 17:13:39 Uhr
Bei mir isses von 300 auf 317 hoch. Lohnt also schon
Autor tyco
 - 06. Februar 2009, 17:23:11 Uhr
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.
Autor Burn.Proof
 - 06. Februar 2009, 10:10:48 Uhr
Der Clint berchnet ja die tazächliche Rate. Die ist bei mir gestiegen. Wird bei Core Throughput in dem Feld Summary/Rate angezeigt.
Autor tyco
 - 05. Februar 2009, 21:32:41 Uhr
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.
Autor Burn.Proof
 - 05. Februar 2009, 20:01:19 Uhr
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 ?
Autor lutzlustig
 - 04. Februar 2009, 11:51:35 Uhr
Wie geht das mit den großen Blöcken? einfach nur den aktuellen beta-proxy oder muß man da noch was einstellen?

Ciao
Autor Burn.Proof
 - 04. Februar 2009, 10:45:54 Uhr
O ha, endlich funktionierts. 105 gerechnet in großen packeten und 105 angerechnet. Es geschehen noch Wunder.
Autor lutzlustig
 - 02. Februar 2009, 22:24:45 Uhr
Ich finde den Core#6 am schnellsten, aber er blockiert auch am meisten.

Ciao
Autor Burn.Proof
 - 02. Februar 2009, 14:28:07 Uhr
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.
Autor Schwermetaller
 - 01. Februar 2009, 20:42:22 Uhr
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?
Autor tyco
 - 01. Februar 2009, 11:10:46 Uhr
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.
Autor tyco
 - 29. Januar 2009, 17:46:53 Uhr
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.
Autor Burn.Proof
 - 29. Januar 2009, 14:12:11 Uhr
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. :/
Autor Noreia
 - 29. Januar 2009, 06:41:08 Uhr
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.