BoincCore für non-CPU-Projekte (ATI-GPU)

Twodee

Lord of the Stats, Special, ,
Mitglied seit
18.09.2006
Beiträge
13.802
Renomée
404
  • RCN Russia
  • Spinhenge ESL
  • Docking@Home
  • BOINC Pentathlon 2012
+++ Update +++

Wer Probleme beim Zusammenspiel von MW- ATI-GPU und anderen CPU-Projekten hat, sollte diesen modifizierten BoincCore ausprobieren:

Download: click

Dazugehörige Konfiguration

Code:
<cc_config>
	<options>
		<report_results_immediately>1</report_results_immediately>
		<zero_debts>1</zero_debts> 
		<start_delay>10</start_delay> 
	</options>

	[I][B]<projects_options>[/B]
		<projectname>milkyway@home</projectname>
		<timeintervall>900</timeintervall>
		<hostinfo_ncpus>8</hostinfo_ncpus>
		<requestworktime>3600</requestworktime>
		<use_ncpus>3</use_ncpus>
		<avr_ncpus>0</avr_ncpus>
		<high_prio>1</high_prio>
	[B]</projects_options>[/B][/I]

                [I][B]<projects_options>[/B]
                                <projectname>Collatz Conjecture</projectname>
		<timeintervall>1800</timeintervall>
		<hostinfo_ncpus>16</hostinfo_ncpus>
		<requestworktime>3600</requestworktime>
		<ignore_projectdelay>1</ignore_projectdelay>  
		<hide_stderr_txt>1</hide_stderr_txt>
		<use_ncpus>1</use_ncpus>
		<avr_ncpus>0</avr_ncpus>
		<realtime_prio>1</realtime_prio>
	[B]</projects_options>[/B][/I]

</cc_config>

Erläuterung:

<projectname>
definiert das Projekt, welches nachfolgende Einstellung betrifft
(milkyway@home oder Collatz Conjecture, Groß/Kleinschreibung ist egal)
Hinweis: Für andere Projekte wurden diese Erweiterungen vorerst gesperrt.


<timeintervall>

Zeitintervall in Sekunden für das Nachfragen von neuer Arbeit
(15 Minuten = 900 Sekunden bei MW)

<hostinfo_ncpus>
definiert die Anzahl der Cores für die Arbeit benötigt wird
(mehr als 8 spielt bei MW keine Rolle, da MW nur Systeme mit max. 8 Cores je 6 WUs versorgt)

<requestworktime>
definiert die gewünschte Arbeitszeit je Core in Sekunden nach der gefragt werden soll
(optimal: 3600 Sekunden)


<use_ncpus>

definiert die Anzahl der gleichzeitig laufenden Tasks, unabhängig von freien/benutzten CPU-Cores durch andere Projekte
(je nach ATI-Karte zwischen 3 und 5 bzw. 6 und 10 bei Multi-GPU
0 = normales Scheduling)

<avr_ncpus>
definiert die (interne) Gewichtung der einzelnen Tasks
(für MW sollte es 0 sein)

<high_prio>1</high_prio>
startet den Task mit Highest Prio, lindert evtl. das Bremsen der GPU-App durch andere Projekte

/** NEU **/

<ignore_projectdelay>1</ignore_projectdelay>
=> ignoriert das veranlasste Warten seitens des Projektes

<realtime_prio>1</realtime_prio>
=> task wird mit realtime-prio gestartet, nur für GPU-Projekte mit NV Karte zu empfehlen (collatz)

<hide_stderr_txt>1</hide_stderr_txt>

=>unterdrückt die Textausgabe in stderr_txt [result], z.b. in MW, wenn man nicht möchte das die app alles über das verwendete System ausplaudert


Voraussetzung: BoincManager der Version 6.6.x muss installiert sein.

Anleitung:

1. Boinc komplett beenden [Komplett beenden heißt, Manager per Icon im Taskarea (rechts unten) per Rechtsklick auf "Beenden" schließen, die Frage nach alle Wissenschaftliche Prozesse beenden mit "ja" beantworten".]
2. Boinc.exe mit der bereits vorhandenen Datei im Installationsverzeichnis ersetzen.
3. cc_config.xml im Boinc-Data-Verzeichnis entsprechend erweitern (siehe oben) [falls diese nicht vorhanden ist, so kann die mitgelieferte Datei benutzt werden]

Nachtrag: Wo gehört die cc_config.xml Datei hin?

(Sofern man die Projekt-Pfadangabe bei der Installation nicht geändert hat)

Windows Vista und Windows7: C:\ProgramData\Boinc
Windows2000/XP/2003: C:\Dokumente und Einstellungen\All Users\Anwendungsdaten\BOINC

Anmerkung 2:
Dieser BoincCore ersetzt nicht die ATIApp, diese wird nach wie vor benötigt.
Infos findet man dazu hier: klick
 
Zuletzt bearbeitet:
:)
du änderst aber hoffentlich die prio des worker-threads, das müßte mehr bringen.
 
:)
du änderst aber hoffentlich die prio des worker-threads, das müßte mehr bringen.
Mehr als was? Du hast es doch noch gar nicht ausprobiert :P
Weiß ich daher so genau, weil außer mir (zum Test) das bisher keiner runter geladen hat.
Übrigens bringt es noch mehr, die Prioritätsklasse des ganzen Prozesses anzuheben, als nur die Priorität des Worker-Threads (innerhalb der Idle-Prioritätsklasse) auf hoch zu stellen. Aber ich denke, das macht Dein Client schon ganz richtig (genau wie meine App) :]
 
Mehr als was? Du hast es doch noch gar nicht ausprobiert :P
Ich kanns mir aber gut vorstellen *buck*
Weiß ich daher so genau, weil außer mir (zum Test) das bisher keiner runter geladen hat.
Es gibt eine neue ATIApp?

Übrigens bringt es noch mehr, die Prioritätsklasse des ganzen Prozesses anzuheben, als nur die Priorität des Worker-Threads (innerhalb der Idle-Prioritätsklasse) auf hoch zu stellen. Aber ich denke, das macht Dein Client schon ganz richtig (genau wie meine App) :]
Also wenn der Prozess sowie der Workerthread auf High steht, müßte es am optimalsten laufen, oder?
 
Es gibt eine neue ATIApp?
Sonst hätte ich es ja nicht erwähnt ;)
Also wenn der Prozess sowie der Workerthread auf High steht, müßte es am optimalsten laufen, oder?
Nun, vielleicht sollte man etwas vorsichtiger da ran gehen, damit man den Windows-Scheduler nicht völlig aus dem Takt bringt :]
Damit eine GPU-App gegenüber CPU-Boinc-Applikationen bevorzugt wird (was wegen Polling der GraKa wünschenswert ist), reicht es im Prinzip eine Stufe höher zu gehen. Stellt man den gleich auf höchste Priorität, so hat sie auch Vorrang gegenüber normalen Anwendungen, nicht nur vor anderen BOINC-Apps. Die normale Prioritätsklasse stellt sie den Nutzeranwendungen gleich. Wie man die Prioritäten der Threads innerhalb der Klasse des Prozesses einordnet, ist dagegen hier nicht ganz so wichtig.
.
EDIT :
.

Dein Client funktioniert soweit ganz gut (X2 mit HD4850).

Hatte anfangs Probleme mit dem workfetch bei MW (beachtet der Client jetzt die deferred communication time?), habe aber dann einfach den timeintervall Parameter wieder etwas erhöht (hatte den Originalwert runter gestellt) und jetzt läuft es erstmal tadellos. Hoffe mal das bleibt so. Zu den Prioritäten kann ich nichts sagen, da wie erwähnt die neue MW-App die selber schon setzt.

Kurzum, Bugs habe ich erstmal nicht gefunden. (im Gegensatz zu Crunch3rs Version)
 
(beachtet der Client jetzt die deferred communication time?)

Ja, das habe ich wieder aktiviert ;)

Auch wenn MW z.B. auf No-New-Work etc. steht, wird (im Gegensatz zur früheren Version) nicht mehr nach Arbeit gefragt.
 
So lasse es mit MW / collatz laufen.....hehe bisher ohne Probs

endlich mal 99% GPU Auslastung :P
 
hier mal ein paar Daten nach 24h

Core 2 6300@2800MHz - XPPro - 2GB RAM - Radeon HD4850 1GB RAM - MB Gigabyte 965P-DS3P F6

Es laufen immer 4 WUs gleichzeitig (2x MW und 2x collatz)

MW ca 46K/Tag collatz 6K/Tag = 52K/Tag - Respekt Twodee :o

und das mit nur einen PC
index.php
 
Bei meiner 9800GT bewirkt das einstellen des tasks auf Echtzeit einen sofortigen Abbruch der Berechnung.
Meine GTX275 läuft dann noch einen Tick besser:)
 
meine 8800GT Karten laufen nur auf Echtzeit. Aber wenigstens kann man die 3,98 verbleibenden Cores sinnvoll nutzen ;D
 
Hmm...hab gerade unter Win7-64 von 6.10.4 auf 6.6.36 downgegradet und dann den optimierten BOINC-Core draufgehauen.

Nun versucht er sich die ganze Zeit mit localhost zu verbinden, schafft es aber nicht un es gibt ne Fehlermeldung.

Any Hints?

Greets
SDI

Edith: Jetzt gehts. Reproduzierbar: Ich musste erst nach der Installation von 6.6.36 einmal den Manager starten, dann beenden und den optimierten Boinc-Core draufpacken. Ohne Start der alten exe gehts nicht...
 
Zuletzt bearbeitet:
Sobald ich etwas Zeit finde, erweitere ich den 6.10.4er um diese Funktionen hier.
 
Das wäre echt Klasse ;)

Evtl. solltest du aber den 6.10.6er nehmen, die Bugs im 4er sind IMHO ziemlich schlimm...
Obwohl ich als Coder-DAU keinen Plan habe, wo sich diese Bugs verstecken...

Greets
SDI
 
<hostinfo_ncpus>
definiert die Anzahl der Cores für die Arbeit benötigt wird
(mehr als 8 spielt bei MW keine Rolle, da MW nur Systeme mit max. 8 Cores je 6 WUs versorgt)

Das stimmt so nicht, ich hatte beim Testen auch schonmal ein Limit von 96 WU/s pro Host (bei Ncpus = 64 glaube ich in der cc_config)
 
Damals war das Limit definitiv bei 6 pro Core bei max. 8 Cores. Es würde mich nicht wundern, wenn sich das mittlerweile geändert hätte ;)
 
Zuletzt bearbeitet:
Zurück
Oben Unten