Rumpelkammer: PCGH Folding@Home-Thread II

[Amigafan]

@brooker

Du hast es leider immer noch nicht verstanden:
Multi-Threating bringt nichts, wenn der Programm-Thread als Single-Thread programmiert wurde - das kannst Du nicht mit derAnzahl der zugewiesenen Kerne ändern!
Außerdem - Du ändert letztendlich auch nicht die Anzahl der Threads, sondern reduzierst die Anzahl der möglich nutzbaren CPU-Kerne - nämlich nur auf die zugewiesenen!
Von daher ist eigentlich nur eine einzige Erkenntnis wichtig:
Für eine leistungsfähige GPU braucht man eine CPU mit hoherSingle-Thread-Leistung (Takt ab etwa 3,5 GHz) und mindestens 2 "echten" CPU-Kernen.

Und - noch eine "Kleinigkeit":
Durch das Weglassen von nicht passenden Resultaten wird das Endergebnis noch "falscher" als ohne - so "erschafft" man ein Ergebniss, welches keiner Nachprüfung standhält.

 

[ProfBoom]

Oder mal anders ausgedrückt:
Ein zweiter zugewiesener Kern kann deshalb schneller sein, weil Windows einen auf einen Kern limitierten Thread nicht woanders ausführen darf.
Andersherum jedoch können andere Prozesse diesen einen Kern nutzen, seine Leistung steht also nicht komplett für den Falt-Thread zur Verfügung.

 

[mattinator]

Da steckt des Pudels Kern. Die Kern-Zuweisung bringt nur einen indirekten Vorteil, da das Windows-Scheduling zum Vorteil des Folding-Threads "durcheinandergebracht" wird. Je weniger "nebenher" auf dem System läuft und je höher die Rohleistung eines Kerns ist, desto geringer wird dieser Vorteil ausfallen.

 

[Amigafan]

@ProfBoom und mattinator

Auch das ist leider nicht ganz richtig, denn:
Eine Zuweisung eines Threads auf einen oder zwei Kerne bringt nur etwas, wenn ich:
1. ein relativ ausgelastetes System benutze, welches meinen Thraed "behindern" könnte und
2. ich gleichzeitig dafür sorge, dass die zugewiesenen CPU-Kerne ausschließlich für "mein" Programm frei bleiben - also für jede weitere Nutzung sperre!

Und das ist mit Sicherheit nicht der Sinn in einer Multi-Task-Umgebung!

 

[brooker]

@brooker

Du hast es leider immer noch nicht verstanden:
Multi-Threating bringt nichts, wenn der Programm-Thread als Single-Thread programmiert wurde - das kannst Du nicht mit derAnzahl der zugewiesenen Kerne ändern!
Außerdem - Du ändert letztendlich auch nicht die Anzahl der Threads, sondern reduzierst die Anzahl der möglich nutzbaren CPU-Kerne - nämlich nur auf die zugewiesenen!
Von daher ist eigentlich nur eine einzige Erkenntnis wichtig:
Für eine leistungsfähige GPU braucht man eine CPU mit hoherSingle-Thread-Leistung (Takt ab etwa 3,5 GHz) und mindestens 2 "echten" CPU-Kernen.

Und - noch eine "Kleinigkeit":
Durch das Weglassen von nicht passenden Resultaten wird das Endergebnis noch "falscher" als ohne - so "erschafft" man ein Ergebniss, welches keiner Nachprüfung standhält.

... entschuldige bitte, aber ich weiß nicht was ich immer noch nicht verstanden haben soll.? Ich habe mit meinen Fazit zu den Testergebnissen nichts anderes geschrieben als Du hier sagst.

"Multi-Threating bringt nichts" - Unterstützt der FAH-Client Multi-Core-Betrieb? Im Test konnte ich darauf leider keine Hinweise finden.

"Für eine leistungsfähige GPU braucht man eine CPU mit hoherSingle-Thread-Leistung (Takt ab etwa 3,5 GHz ...." - Bei meinem Setup ohne GPU-OC limitierte die CPU ab ca. 3.6 GHz die GPU nicht mehr. Nach einem GPU OC lag jedoch wieder eine Limitierung vor. Diese konnte Du die Taktsteigerung der CPU auf 4.5 GHz aufgehoben werden. Ein CPU-Limit muss für jedes System individuell ermittelt werden.

Also erlaube mir bitte die Frage, was ich deiner Meinung anders formulieren muss, dass es Deiner Meinung nach stimmt? Ich möchte, wenn ich einen Fehler gemacht habe diesen bereinigen.

PS: Du schreibst "(Takt ab etwa 3,5 GHz) und mindestens 2 "echten" CPU-Kernen." - wie kommst Du auf die 2 echten Kerne?

 

[brooker]

@ProfBoom und mattinator

Auch das ist leider nicht ganz richtig, denn:
Eine Zuweisung eines Threads auf einen oder zwei Kerne bringt nur etwas, wenn ich:
1. ein relativ ausgelastetes System benutze, welches meinen Thraed "behindern" könnte und
2. ich gleichzeitig dafür sorge, dass die zugewiesenen CPU-Kerne ausschließlich für "mein" Programm frei bleiben - also für jede weitere Nutzung sperre!

Und das ist mit Sicherheit nicht der Sinn in einer Multi-Task-Umgebung!

... aber darum geht es doch. Nicht jeder der faltet hat nen reinen Falter der dafür optimiert ist. Werseinen Gamer anwirft und aufm Desktop nebenbei rödelt, muss möglichst optimale Bedingungen schaffen. Er weist 2 Threads zu und legt die Prio hauf hoch. Dann kann er problemlos daddeln und die GPU optimal falten. Multitasking, Auslastung usw. hin oder her. Das ist die Handlung und das einfache Hausmittel was einen Einsteiger oder Gelegenheitsfalter optimale Ergebnisse bescherrt.

 

[ZobRombie]

Ernstgemeinte Verständnisfrage: ab welcher GPU beginnt "leistungsfähige"?

Ich nutze zum Befeuern der 960 einen zweckentfremdeten i5-5675C, welcher bis zu 3,6 GHz taktet. Wenn ich über die Energieeinstellungen die maximale Prozessorleistung begrenze, etwa minimal auf 800 MHz, dann gibt es keinen gefühlten Falt-Leistungsunterschied - die PPD schwanken so oder so zwischen 120k und 160k PPD. Ich erfreue mich dann am deutlich gesunkenen Verbrauch der CPU.

Das führte bei mir gedanklich dazu, dass ich für einen "echten" dedizierten Falter, etwa mit der besagten 960, dann gleich eine sparsame Plattform als Basis zu verwenden gedachte. Sei es nun auf Braswell-Basis, sei es ein Xeon E3-1220L oder ein Celeron-T/Pentium-T/i3-T.

Hat die Diskussion gerade jetzt mehr wissenschaftlich/theoretische Natur für das "letzte Quentchen" an Faltleistung oder kann ich die Idee mit Braswell oder E3-1220L auch praktisch begraben? Gilt das alles jetzt nur für die Nvidia GPUs? Weil die AMD Varianten ja wohl weniger CPU-Last erzeugen - aber müsste ich dann trotzdem mehr CPU-Takt einplanen, um auch diese nicht zu bremsen?

Oder kurz:
Kann ein Taktdefizit auch Grund für WU-Bearbeitungsfehler sein? Oder erreiche ich dann einfach nur 100%-X der maximalen Faltleistung?

Vielleicht etwas wirr, aber so ist mir tagesaktuell auch .

Grüße

 

[brooker]

@ZobRombie: das Thema Limitierung gilt nur für Nvidias, denn bei den GPUs muss die CPU die WU "vorkauen". Daher hast Du über die gesamte Zeit des Faltens eine deutliche CPU-Last auf einem Thread. Deine Frage ist gut und berechtigt. Ich würde vermuten, dass bei einem 3570K 2.8 GHZ ausreichen sollten. Deine CPU sollte daher ausreichen. DU kannst aber auch den Selbsttestmachen: möglichst alles was Du nicht brauchst aufm Rechner ausmachen, die WU auf Prio "hoch setzen" und zwei Threads zuweisen. Dann in den Taskmanger schauen. Ist die Auslastung die die WU erzeugt bei 25% liegt noch ein Limit vor. Wenn kleiner, bist Du raus und die GPU kann optimal performen. Betreibst Du im Anschluss OC an der GPU, verschiebt sich der Anspruch an die CPU nach oben.

Weiterer Effekt, wenn auch nicht von so großer Auswirkung ist, dass schnellere CPUs die WU am Anfang schneller auspacken können und somit der Faltprozess schneller starten kann. Gerade bei meinem kleinen FAlter dauert das bei froßen WUs oft einige Minuten.

 

[mattinator]

Eine Zuweisung eines Threads auf einen oder zwei Kerne bringt nur etwas, wenn ich:
1. ein relativ ausgelastetes System benutze, welches meinen Thraed "behindern" könnte und

Da in einem aktuellen System (mit SSD) kaum noch etwas außer der CPU selbst "bremst", hat man bei jeder aktiven Anwendung zumindest auf einem CPU-Kern ein ausgelastetes System.

2. ich gleichzeitig dafür sorge, dass die zugewiesenen CPU-Kerne ausschließlich für "mein" Programm frei bleiben - also für jede weitere Nutzung sperre!

Wer sagt Dir, dass die manuelle Änderung der core affinity nicht gerade das tut, bzw. mindestens den "normalen" Mechanismus des Betriebssystem "stört" ? Oder hast Du den Windows Scheduler programmiert ?

Außerdem wäre es aus meiner Sicht schon möglich, dass mit forcierter affinity z.B. der für das Scheduling erforderliche Aufwand sinkt. Denn auch jedes Umschalten zwischen den CPU-Kernen durch den Scheduler kostet Rechenleistung.

 

[Amigafan]

@brooker

1. Lese bitte einmal Deine Darstellung durch - ich habe Probleme, Deinem "Ergebnis" zu folgen - mir fehlt nämlich z. B. die Angabe der Zeiten, als die CPU mit 3,6GHz und gleichzeitig die GPU mit 1550MHz läuft.
Die vorhandenen Bilder bringen ebenfalls keine Auflösung (ich sehe z. B. CPU@3800MHz und TPF auf 5:51 - aber mit welchem GPU-Takt)?
Und - die wichtigste Frage - wo (Client/HFM) und über welchen Zeitraum (Anzahl der Frames) wurde die TPF ermittelt?

2. Eine CPU mit nur einem Kern behindert immer das GPU-Falten der neueren WU-Generationen (Core18, in besonderem Maße Core21), weil auch das Betriebssystem "seinen Teil" braucht - also mindestens 2 Kerne - "echt" daher, weil ein nur freier "Hyperthreating-Core" z. B. bei einer 4+HT-Core-CPU ebenfalls nicht leistungsfähig genug wäre .

3. Ob der Client multi-thread-fahig ist, ist irrelevant - es zählen die GPU-FahCores. Und diese sind - leicht feststellbar - nur single-thread-fähig, sonst würden Windows bzw. Linux den GPU-Cores mehrere Kerne zur Verfügung stellen.


@mattinator

Du mußt Dir nur einmal die Mühe machen, das "Vor- und Nachher" zu kontrollieren - und Du wirst erstaunt feststellen, dass Deine Vermutung leider falsch ist.
Benutze einmal ProzessLasso - es zeigt Dir von jedem laufenden Thread an, auf welchem CPU-Kern dieser zugewiesen werden kann. Dann ändere die core-affinity mit Bill2 und kontrolliere, ob dadurch an der Zuweisung für alle anderen Threads etwas geändert wurde . . .

BTW:
Der Grund für das "nicht-automatische" Sperren ist ganz einfach - es gibt meines Wissens nach einige wenige Threads in Windows, die zwingend auf den ersten CPU-Core (Core0) angewiesen sind - sollte also "irrtümlich" der Core0 manuell zugewiesen werden und es gäbe die Automatik der Sperrung für alle anderen Threads, wäre der Absturz vorprogrammiert - und das sollst Du schon selber tun . . .

 

[XeT]

Zob dein plan sollte aufgehen, mein pentium anniversary läuft derzeit ohne oc bei 3,2ghz und ist bei der 980 auf 88-90%

 

[mattinator]

@mattinator
Du mußt Dir nur einmal die Mühe machen, das "Vor- und Nachher" zu kontrollieren - und Du wirst erstaunt feststellen, dass Deine Vermutung leider falsch ist.

Die Mühe werde ich mir nicht machen, da ich im Moment nicht unter Windows arbeite und Prozess-Lasso mir nicht (wieder) auf den Rechner kommt.
Empirisch ermittelte Daten sind nur mit einer hinreichend großen Anzahl von Stichproben beweiskräftig. Mangels des Zugriffs auf den Source-Code des Windows Schedulers werden wir hier wohl nicht endgültig klären können, welche konkreten Auswirkungen die Änderung der affinity "zugunsten" des Folding-Cores auf die Funktionsweise Schedulings hat. Zumindest hat sich brooker die Mühe gemacht, die Einflüsse von CPU-Leistung, priority und affinity auf das Folding zu analysieren und ist zu einem Ergebnis gekommen, das zumindest Tendenzen erkennen lässt. Das ist erst einmal alle Anerkennung wert. Inwieweit sich seine Empfehlungen verallgemeinern lassen, hängt dann doch von der konkreten Hardware und den individuellen Nutzungs-Szenarien jedes einzelnen ab. Meine kurzen Tests unter Linux ergaben keinen merklichen Vorteil durch Änderung der affinity. Allerdings kann man das Scheduling von Linux nicht mit dem von Windows vergleichen, selbst unter den verschiedenen Windows-Versionen gibt es z.T. erhebliche Unterschiede in der Funktionsweise des Schedulers.

 

[Amigafan]

@mattinator

Bevor Du Dich weiter in nebulöse Vermutungen verstrickst, bleiben wir lieber bei (für Jedermann) nachprüfbaren Fakten, die da lauten:
Die Core-Affinitätszuweisung für einen Thread sperrt keine anderen Threads bei der Nutzung desselben CPU-Cores, alleine die Priorität der Prozesse beeinflußt die tatsächliche Core-Nutzung.
Im Gegenteil - durch die Affinitätszuweisung werden dem Prozess nur bestimmte CPU-Cores zur Nutzung vorgeschrieben, eine Nutzung anderer als der zugewiesenen CPU-Cores wird gesperrt.

Dieses Verhalten gilt sowohl für Windows 7 als auch Windows 8 (und vermutlich damit auch zumindestens für 8.1, da aber nicht von mir überprüft).

Edit:
Hier findest Du ein gutes Beispiel, mit dem Du ganz einfach die Standardzuweisung aller Threads mit Hilfe des Task-Managers von Windows überprüfen und gleizeitig eine Core-Affinitätszuweisung durchführen kannst.
Change the Processor Affinity setting in Windows 7 to gain a performance edge - TechRepublic


@Bumblebee

Bei mir läuft seit gut 2 Tagen der von Dir genutzte Treiber 355.82 - einen Unterschied zu dem 359.00 WHQL ist - zumindest aus falttechnischer Sicht - nicht auszumachen.
Wenn Du also nicht auf erweiterte Spieloptimierungen angewiesen bist, bleibe beim 355.82.

 

[mattinator]

@Amigafan
Alter Klugs... Vielleicht solltest Du meine Posts mal genau lesen. Ich habe das nirgends behauptet:

Die Core-Affinitätszuweisung für einen Thread sperrt keine anderen Threads bei der Nutzung desselben CPU-Cores

Der Hauptgedanke war, dass durch Änderung der Affinität möglicherweise (wahrscheinlich) der Scheduling-Overhead reduziert wird. Das Gegenteil kannst Du auch nicht wirklich beweisen. Fakt ist, dass aktuelle Scheduler in allen Betriebssystemen unter anderem auch die aktiven Threads zwischen den einzelnen "echten" und "virtuellen" Kernen einer CPU "durchreichen" / wechseln, um den Boost- und Stromspar-Mechanismen der CPU's Rechnung zu tragen. Das wird mit der Fixierung der affinity eingeschränkt, was logischerweise den Scheduling-Overhead einschränkt. Ob daraus ein Performance-Vorteil für das konkrete Nutzungs-Szenaria erwächst, hängt vom konkreten Anwendungsfall ab (habe fertig).

 

[XeT]

So damit wir mal ein neues Thema starten können und nicht jeder mit Wissen und mit Differenzen um sich werfen muss. Ich würde mit ein nas anschaffen wollen. Etwas zur datensicherheit und leichterem verteilen. Kommt man stromtechnich mit einem Selbstbau halbwegs an die fertigen ran? Könnte ich mit selbstbau eine gpu zum Falten nutzen?

 

[Amigafan]

@mattinator

Dann lese Dir bitte Deinen eigenen Post durch - interessant vor allem nach dem 2. Zitat:
http://extreme.pcgameshardware.de/f...-folding-home-thread-ii-3201.html#post7861441

Und - wenn ich schlicht nur verhindern will, dass belegbar falsche Darstellungen richt gestellt werden, hat das nichts mit Klugscheißerrei zu tun, sondern der Wahrheit!
Mehr werde ich dazu nicht mehr sagen . . .


@XeT

Prinzipiell ist das möglich - allerdings bin ich mir nicht sicher, ob Du ein reines NAS zum Falten bringst - das hängt letztendlich auch von der verwendeten Hardware ab (ich bin mir z. B. nicht sicher, ob ein NAS eine PCIE-Schnittstelle mitbringt).

 

[XeT]

Die fertigen sicher nicht. Aber selber bauen geht da ja auch. Ich glaub ich mach am besten erstmal mal nur,ein fileserver mit freigegeben festplatten und raid. Wird echt mal Zeit das wir umziehen und ich das ganze IT-Konzept erneuern kann.

 

[mattinator]

@mattinator

Dann lese Dir bitte Deinen eigenen Post durch - interessant vor allem nach dem 2. Zitat:
http://extreme.pcgameshardware.de/f...-folding-home-thread-ii-3201.html#post7861441

Und - wenn ich schlicht nur verhindern will, dass belegbar falsche Darstellungen richt gestellt werden, hat das nichts mit Klugscheißerrei zu tun, sondern der Wahrheit!
Mehr werde ich dazu nicht mehr sagen . . .

Zitat von Amigafan
2. ich gleichzeitig dafür sorge, dass die zugewiesenen CPU-Kerne ausschließlich für "mein" Programm frei bleiben - also für jede weitere Nutzung sperre!
Wer sagt Dir, dass die manuelle Änderung der core affinity nicht gerade das tut, bzw. mindestens den "normalen" Mechanismus des Betriebssystem "stört" ?

Schade, dass Du scheinbar eine rhetorische Frage und "falsche Darstellung" nicht unterscheiden kannst. Noch mal inhaltlich: wenn ein Thread einen CPU-Kern zu 100% auslastet, die affinity auf einen bestimmten Kern eingeschränkt wurde und das System insgesamt über alle Kerne nicht am Limit läuft, wird das in der Realität bedeuten, dass der Scheduler für die anderen Threads die anderen nicht benutzten Kerne nutzt. Oder sehe ich das falsch ?

 

[Amigafan]

Die fertigen sicher nicht. Aber selber bauen geht da ja auch. Ich glaub ich mach am besten erstmal mal nur,ein fileserver mit freigegeben festplatten und raid. Wird echt mal Zeit das wir umziehen und ich das ganze IT-Konzept erneuern kann.

Vielleicht kann Dir A.Meier-PS3 helfen, der hatte (oder hat sogar noch) ein ähnliches Projekt laufen.

 

[XeT]

Meine Nano sitzt gerade an Core17 Project 10468(0,493,232) -> TPF 3min 16sec PPD:393588
Ich würde sagen nachts bitte mehr davon.