Optimierte MilkyWay@home Applikation
- Ersteller Twodee
- Erstellt am
Ich hab das gemacht was du geschrieben hast, aber trotzdem zuckelt es ganz schön, obwohl die CPU Auslastung sehr gring ist.Also die fehlende Flash-Werbung würde ich nicht als Grafikfehler bezeichen
Hmm, keine Ahnung, eventuell kommt der XP32-Grafikkartentreiber das nicht richtig hin, seine Kommandos immer bei den WU-Wechseln dazwischen zu schieben (sollte bei einer HD38x0 eigentlich noch für mindestens 6Hz Bildwiederholfrequenz ausreichen). Du kannst ja mal ausprobieren, nur eine WU laufen zu lassen. Dazu in der app_info.xml die Werte avg_ncpus und max_ncpus mal beide auf 2 setzen (die Einträge gibt es je zweimal). Für das Editieren der app_info.xml gilt das Gleiche wie für die Installation der Apps, BOINC sollte vorher beendet werden.
Übrigens sollte das bei einer 3870 eher alle 24s bzw knapp 35s eine WU sein (es sei denn, Du hast eine der wenigen ganz kurzen erwischt, die wohl auch rumschwirren). Denk dran, das BOINC CPU-Zeit anzeigt
Wenn ich 4 WU's gleichzeitig rechnen lasse, dann kann man nicht mehr viel am PC machen.
Hier die Zeiten:
.
EDIT :
.
Sobald ich ein anderes Projekt dazu schalte hängt sich der VPU auf.
Emploi
Grand Admiral Special
..
Sobald ich ein anderes Projekt dazu schalte hängt sich der VPU auf.
Dagegen hilft die "Nutze auf Muliprozessorsystem"-Option auf 70% zu stellen. Also das ein Core mindestens frei ist... (Bei mir sind zwei frei) Bei dir sollten höchstens 50% zugelassen werden...
Zuletzt bearbeitet:
Crashtest
Redaktion
☆☆☆☆☆☆
WARNUNG:
DIE BEI AMD/ATI HAM GEFUSCHT MIT DEM 9.2 CATALYST:
DIE CAL-APIs haben neuen Namen und das SETUP vom Catalyst 9.2 löscht die alten Dateien !
FRÜHER :
amdcalcl.dll
amdcaldd.dll
amdcalrt.dll
bzw
amdcalcl64.dll
amdcaldd64.dll
amdcalrt64.dll
NU:
aticalcl.dll
aticaldd.dll
aticalrt.dll
bzw.
aticalcl64.dll
aticaldd64.dll
aticalrt64.dll
--> IST EIN PROBLEM FÜR GISPEL-MW-APP
DIE BEI AMD/ATI HAM GEFUSCHT MIT DEM 9.2 CATALYST:
DIE CAL-APIs haben neuen Namen und das SETUP vom Catalyst 9.2 löscht die alten Dateien !
FRÜHER :
amdcalcl.dll
amdcaldd.dll
amdcalrt.dll
bzw
amdcalcl64.dll
amdcaldd64.dll
amdcalrt64.dll
NU:
aticalcl.dll
aticaldd.dll
aticalrt.dll
bzw.
aticalcl64.dll
aticaldd64.dll
aticalrt64.dll
--> IST EIN PROBLEM FÜR GISPEL-MW-APP
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
THX,
9.1 CAL Treiber waren Version:
6.14.10.158 vom 14.01.2009
Die 8.12 waren
6.14.10.145 vom 01.12.2008
ziemlicher Sprung ...
Also läuft es so dann problemlos ?
Crashtest
Redaktion
☆☆☆☆☆☆
Gipsel-MW-App kannsch mangels DP-Graka nich testen, aber die SDK-Samples und auch Everest 5.0.1658 akzeptieren die "neuen" CAL-Apis wennse "richtig" heißen
ps ich installiere grad Srv03 auf dem V8-Shanghai ... 1-2h und er BOINC'ed
ps ich installiere grad Srv03 auf dem V8-Shanghai ... 1-2h und er BOINC'ed
Habe dazu auch eine tolle Antwort von AMD bekommen:
Echt toll!michael.chu@amd.com schrieb:
Da wird das schon eine Firma unter dem Namen AMD und aus marketingtechnischen Gründen ändern die die für den Normalnutzer total unwichtigen Dateinamen von AMD*.dll auf ATI*.dll ab
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Wirklich mysteriös ... Marketingmaßnahme in nem Bereich wo sie nun wirklich 0,0 Auswirkung hat.Echt toll!
Da wird das schon eine Firma unter dem Namen AMD und aus marketingtechnischen Gründen ändern die die für den Normalnutzer total unwichtigen Dateinamen von AMD*.dll auf ATI*.dll ab
Oder glaubt da jetzt wirklich einer, dass jetzt Programmierer in Scharen von nV / CUDA überlaufen, da da jetzt ATi* steht.
Wieder mal typisch AMD, Marketing für wo am Unnötigsten.
Sollen sie mal ne deutliche Namensunterscheidung zw. AM2+ und AM3 CPUs machen, da herrscht mal wieder ein Chaos ..
Naja wird sich wohl nie ändern.
ciao
Alex
Crashtest
Redaktion
☆☆☆☆☆☆
AMD = 
naja man kennt ja bereits solche sinnlosen Aktionen von AMD;
Kleiner Zwischenbericht: der V8 is am Netz, hat "nur" noch Probleme mit ATI-Graka und 8GB-RAM BSODs.... MW-Link http://milkyway.cs.rpi.edu/milkyway/show_host_detail.php?hostid=50650
CAL:
Hilfsweise könnte man auch mit nem HEX-Editor die Depends in der Exe umarbeiten ... bis die die Lib's ändern
naja man kennt ja bereits solche sinnlosen Aktionen von AMD;
Kleiner Zwischenbericht: der V8 is am Netz, hat "nur" noch Probleme mit ATI-Graka und 8GB-RAM BSODs.... MW-Link http://milkyway.cs.rpi.edu/milkyway/show_host_detail.php?hostid=50650
CAL:
Hilfsweise könnte man auch mit nem HEX-Editor die Depends in der Exe umarbeiten ... bis die die Lib's ändern
Zuletzt bearbeitet:
Emploi
Grand Admiral Special
Da können sich doch nur ein paar Intelfanboys beschwert haben. 
Wie ja alle Welt weiß und ich es neulich wieder in einem Forum las: "Intel läuft besser mit ATI und AMD besser mit nvidia".... und Intel läuft gar nicht mit AMD! 
fogzone
Grand Admiral Special
Mal eine Frage am Rande: Auf meinem i7 mit 4870 unter BOINC 6.4.5. läuft die GPU-APP wirklich super. Ist es möglich, dass Graka und CPU gleichzeitig MW rechnen? Derzeit rechnet bei mir dann nur noch die GPU wenn ich Gipsels App verwende.
Emploi
Grand Admiral Special
Mit einem BOINC Manager wird es wohl nicht gehen.
Mit deinem i7 könntest du ja noch 6 VMs öffnen...
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Och komm, gönn Deine Rechenleistung nem andren, GPU losem Projekt. Gegenüber der 4870 ist die MW CPU Leistung eh lächerlich
ciao
Alex
Im Prinzip ist das möglich, allerdings müßte ich dazu die GPU-App ändern. Irgendwann wird das sicherlich gehen, im Moment haben aber andere Sachen Priorität.
In der Zwischenzeit würde ich das Gleiche wie Opteron sagen. Rechne einfach ein anderes Projekt zusätzlich zu MW. Die HD4870 macht doch schon genügend Betrieb bei MW
Emploi
Grand Admiral Special
BOINC beenden
Inhalt des Milkyway Verzeichnisses löschen (Pfad: ProgrammData>BOINC>projects>milkyway.cs.rpi.edu_milkyway)
Die drei Dateien (app_info.xml, astronomy*exe und brook.dll) des GPU Archives dort hinein entpacken
Optional: in der App_info Datei einzustellen: <avg_ncpus>0.20</avg_ncpus> <max_ncpus>1</max_ncpus>. Wobei auf einen Quadcore 40WU bei der Einstellung <avg_ncpus>0.10</avg_ncpus> <max_ncpus>1</max_ncpus> berechnet werden, bei <avg_ncpus>0.20</avg_ncpus> 20 und bei <avg_ncpus>1.00</avg_ncpus> 4 gleichzeitig.
BOINC starten
Inhalt des Milkyway Verzeichnisses löschen (Pfad: ProgrammData>BOINC>projects>milkyway.cs.rpi.edu_milkyway)
Die drei Dateien (app_info.xml, astronomy*exe und brook.dll) des GPU Archives dort hinein entpacken
Optional: in der App_info Datei einzustellen: <avg_ncpus>0.20</avg_ncpus> <max_ncpus>1</max_ncpus>. Wobei auf einen Quadcore 40WU bei der Einstellung <avg_ncpus>0.10</avg_ncpus> <max_ncpus>1</max_ncpus> berechnet werden, bei <avg_ncpus>0.20</avg_ncpus> 20 und bei <avg_ncpus>1.00</avg_ncpus> 4 gleichzeitig.
BOINC starten
Zuletzt bearbeitet:
denjo
Grand Admiral Special
hab das gestern mal mit dem 32 bit Client und einer 4830 getestet war leider nicht erfolgreich cat 9.1 VPU Recovery only bei ausschalten kann ich natürlich erstmal neustarten 
ich warte auf Anleitung
ich warte auf Anleitung
Bei mir läuft die 32bit Version problemlos seit 2 Tagen.
Das einzige das stört ist, dass immer nur 24 WUs vorrätig sind (Dualcore) und immer erst neue WUs angefordert werden, wenn die berechnet sind. Kann man da irgendwas ändern?
Das einzige das stört ist, dass immer nur 24 WUs vorrätig sind (Dualcore) und immer erst neue WUs angefordert werden, wenn die berechnet sind. Kann man da irgendwas ändern?
Sixpack44
Lieutnant
Yep...pack Dir nen Quadcore in die Kiste.
Soweit ich weiss, gibts da ein 12 WU Limit pro Core. Dementsprechend hast Du mit nem Dual das Limit erreicht, ansonsten s.o.
Bei mir hat´s geholfen, den Rechner in Ruhe zu lassen und abzuwarten. Nach ner gewissen Zeit pendelt sich das ein und er hat immer genug WUs zur Verfügung.
Und, wie man sieht, es funktioniert...
Soweit ich weiss, gibts da ein 12 WU Limit pro Core. Dementsprechend hast Du mit nem Dual das Limit erreicht, ansonsten s.o.
Bei mir hat´s geholfen, den Rechner in Ruhe zu lassen und abzuwarten. Nach ner gewissen Zeit pendelt sich das ein und er hat immer genug WUs zur Verfügung.
Und, wie man sieht, es funktioniert...
Hallo Leute!
Gibt mal wieder eine neue Version vom GPU-Client.
Das Update ändert nichts an der eigentlichen App, sondern stellt nach der CPU-Erkennung in der 0.19 jetzt auch eine GPU-Erkennung zur Verfügung (abzulesen bei den task details).
Wie gut die funktioniert, müßt ihr mal ausprobieren. Auf meiner Entwicklungskiste mit AMD 780G Chipsatz liefert der Treiber bei einigen Sachen schlichtweg falsche Werte
Also postet mal, was er bei Euch anzeigt!
Als Systemvoraussetzung gilt immer noch Win32/64 mit SSE2-fähiger CPU und eine ATI HD3800er oder 4800er Karte mit Catalyst 8.12 oder 9.1 (9.2 funktioniert im Moment nicht).
Gibt mal wieder eine neue Version vom GPU-Client.
Das Update ändert nichts an der eigentlichen App, sondern stellt nach der CPU-Erkennung in der 0.19 jetzt auch eine GPU-Erkennung zur Verfügung (abzulesen bei den task details).
Wie gut die funktioniert, müßt ihr mal ausprobieren. Auf meiner Entwicklungskiste mit AMD 780G Chipsatz liefert der Treiber bei einigen Sachen schlichtweg falsche Werte
Der RV610 stimmt ja (der HD3200 des 780G ist nur ein im Chipsatz integrierter HD2400 mit UVD), genau wie RAM und Takt. Allerdings hat der nur 40 Shader Units organisiert in einer einzigen SIMD-Einheit mit 8 VLIWs. Keine Ahnung, warum der Treiber da Fantasie-Werte zurückliefert. Aber wenn er bei den wesentlichen Karten das Richtige anzeigt, bin ich schon zufrieden.
Also postet mal, was er bei Euch anzeigt!
Als Systemvoraussetzung gilt immer noch Win32/64 mit SSE2-fähiger CPU und eine ATI HD3800er oder 4800er Karte mit Catalyst 8.12 oder 9.1 (9.2 funktioniert im Moment nicht).
Zuletzt bearbeitet:
Ähnliche Themen
