Rumpelkammer: PCGH Folding@Home-Thread II

[Mr.Knister]

Zum Thema Crimson habe ich auch eine kleine Geschichte zu erzählen

Mein kleiner Falter hat heute eine SSD spendiert bekommen, also stand eine komplette Neuinstallation an. Die Wahl fiel auf Lubuntu 14.04 und spontan auf den nagelneuen "Crimson"-fglrx. Also gleich nach der OS-Einrichtung den Treiber fertig paketiert heruntergeladen, installiert und neugestartet.
...
BIOS-Bildschirm > Lubuntu-Ladebildschirm > blinkender Unterstrich oben Links. Weiter kein Mucks

Um die Ansteuerung der falschen GPU als Fehlerquelle auszuschließen, stöpselte ich auf die iGPU um, jedoch ohne Erfolg.
Strg-Alt-F1 > Login > startx zeigte einige Fehlermeldungen inkl. "Segmentation Fault". Also deinstallierte ich mit "sudo apt-get purge fglrx" den Treiber und seine Konfiguration. So dachte ich.

Denn nach einem erneuten Neustart stellte sich im "Zusätzliche Treiber"-Manager heraus, dass immernoch ein "manuell installierter Treiber" vorhanden war, und auch "lsmod | grep fglrx" förderte den Umstand zutage, dass das entsprechende Kernel-Modul lief. Das ließ ich nicht auf mir sitzen und radierte "fglrx*", und damit auch den "Übeltäter" fglrx-core aus.

Erst dann wurde mir klar, dass ich damit mal das Falten hätte versuchen können, also kam Crimson wieder drauf, und wieder erschien keine grafische Benutzeroberfläche. Da ich nicht wusste, wie man den FAHClient über die Konsole benutzt, die Neugier mich aber dazu trieb, las ich mich mithilfe von "FAHClient --help" ein. Siehe da, ohne von Eurem Gespräch hier zu wissen, stolperte ich über folgende Optionen:

Folding Core:
...
cpu-usage <integer=100>
    The maximum percentage of the CPU a core should use. Not implemented by all
    cores.

 gpu-usage <integer=100>
    GPU usage as a percent from 10-100

Zurück in der Desktopumgebung fielen die niedrigen ppd von ca. 55k auf, also geht's jetzt mit älteren Treibern weiter. Übrigens scheint gpu-usage auch "Not implemented by all cores." zu sein, meine 0x17er-9201 zeigt sich unbeeindruckt.

Mal schauen, ob ich den 14.9er-Catalyst noch vor dem Morgengrauen istalliert bekomme. Nacht allerseits

EDIT

Mission AM1 done: OC abgeschlossen, 2.480MHz bei minimalen Offset. Teste jetzt mal mit ner CPU-WU auf Stabilität

BCLK erhöht? Wenn ja, SATA-Modus AHCI oder IDE? Mein Asus AM1M-A erkennt mit erhöhtem Basistakt und AHCI keine Festplatten mehr; IDE ist suboptimal für SSDs.

 

[Bumblebee]

Täusche ich mich. oder gibt es aktuell Probleme im Castle Bumblestein?

Jein, die Compi's laufen "eigentlich" - offenbar wird aber nicht alles gezählt / übermittelt
Werde dann noch etwas tiefer graben - habe aber auch noch andere Hobbys (wie zB. arbeiten )

 

[A.Meier-PS3]

@Mr.Knister:
War früher auch schon so das man die GPU nur mit 100% Last betreiben konnte sprich nicht über "usage" beeinflussen konnte.

 

[XeT]

Nur mal für zwischen durch, da ich gerade den pentium und die 980 in Stellung bringe. Die Karten nutzen immer 1 Thread für sich oder? Beim ersten versuch ohne oc und programmen waren die Werte grausam mit 100% kompletter CPU auslastung

 

[ZobRombie]

Wird bei dir im frischen Windows vielleicht noch indiziert oder im Hintergrund Updates geladen o.ä.?

 

[XeT]

Ja Updates waren noch da. Wenn ich mittag zurück bin sollte aber win10durch sein. Waren 1 Kern folding und 1 kern rest. Die frage ist halt ob ich über den 2 Kern neben dem entpacken noch mehr rausholen kann. Wenn Zen+neue GPUs kommt soll der pentium 2 AMD's befeuern solange erstmal nur die 980.

 

[ZobRombie]

brooker hatte ja Positives zu berichten, wenn zwei Threads zugewiesen werden.
http://extreme.pcgameshardware.de/f...-limitiert-meine-cpu-die-gpu-beim-falten.html

 

[XeT]

Hm den kannte ich noch garnicht. Dann geht es heute mal ans tuning und dann sollte es wieder warm werden.
Xeon+290 war spürbar die Nano solo bringt keinen heizwert

 

[Amigafan]

@ZobRombie

Deine "Interpretation" stimmt so nicht - außerdem ist der dort angestellte Vergleich leider nutzlos - es fehlen die als "nicht mehr relevant" ausgewiesenen Ergebnisse, um ein vollständiges und damit nachvollziehbares bzw. überprüfbares Ergebnis für Außenstehende zu ermöglichen. So kann das Urteil dieses Vergleiches leider nur lauten:
Wie sie sehen, sehen sie Nichts!
Hinweis: Szenario 4 . . .
Es stellt sich nämlich hierbei für mich die Frage: Brauche ich das zusätzliche Programm überhaupt???

 

[XeT]

PC 2:So pc läuft erst einmal. Derzeit noch keine optimierung vorgenommen: Gpu läuft auf 88% und 320k ppd bei eine core18 6h

Für den PC 1 kann ich weiterhin eine verbessere der TPF für die Córe 17 WUs von 10-15sec bestätigen.
Dafür kann ich mit crimson den Monitor per Windows nicht mehr abschalten. Da muss ich auf dauerBild und den Monitor direkt abschalten. Sonst gibt es einen Blackscreen und keine Punkte

 

[ZobRombie]

@ZobRombie

Deine "Interpretation" stimmt so nicht - außerdem ist der dort angestellte Vergleich leider nutzlos - es fehlen die als "nicht mehr relevant" ausgewiesenen Ergebnisse, um ein vollständiges und damit nachvollziehbares bzw. überprüfbares Ergebnis für Außenstehende zu ermöglichen. So kann das Urteil dieses Verglaiches leider nur lauten:
Wie sie sehen, sehen sie Nichts!
Hinweis: Szenario 4 . . .
Es stellt sich nämlich hierbei für mich die Frage: Brauche ich das zusätzliche Programm überhaupt???

Hallo,

du Sorry, ich stehe gerade irgendwie auf dem Schlauche - was habe ich interpretiert, bzw. gar fälschlich?

Grüße

Edit:

Achso, du meinst den Thread von brooker - da habe ich einfach nur brookers eigene Aussage wiedergegeben. Und mangels eigener Tests meinerseits und in Kombination mit brookers Gründlichkeit/Hingabe stelle ich dies zunächst auch nicht in Frage. XeT sagt, er hätte eine komplett ausgelastete CPU und schlechte Ergebnisse, so dass entsprechend eine CPU-Limitierung denkbar erschien. brooker kommt in seinem Limit-Thread zu der Aussage, dass bei ihm zwei zugewiesene Threads pro WU ein optimales Ergebnis darstellen. XeT widerrum wollte dies testen.

Eine allgemein gültige, verpflichtende Aussage oder Empfehlung zur Nutzung eines Prozess-Managers wollte und habe ich glaube ich auch nicht gegeben.

 

[XeT]

Also für mich hat das genau gepasst. Ich muss noch oc an Tag bringen sonst bin ich im,cpuLimit.

Übrigens von wegen amd-karten sind heiß und laut.
Meine nano ist leider und kühler. Die 980faltet im ref mit 80grad im offenen aufbau.

 

[ZobRombie]

Puh, sie kommt auf 80 Grad? Ich habe nur Erfahrung mit MSI 980er Modellen, die eher bei 50 Grad landen. Sicher, dass die Karten-Kühlung einwandfrei funktioniert? Oder machst du einen passiv-Aufbau?
Ich habe zur Zeit ja nur eine 960 laufen, auch im offenen Aufbau und die liegt faltend bei 40% Lüfterdrehzahl bei 39 Grad.

 

[arcDaniel]

Man muss aber sagen dass es eine Werks-OC ist mit Referenzkühler... Ich hatte sie beim faltem immer mit einer angepassten Lüfterkurve am laufen, damit sie kühler bleibt [emoji3]

 

[XeT]

Hab sie jetzt bei 71grad und hörbaren 65% Lüfter aber morgen gehts ans oc. Wenn sie heis genug wird kann ich das Fenster offen lassen

Ok der Takt mit 1392mhz ist auch mal eben 176mhz über standart

 

[brooker]

@ZobRombie

Deine "Interpretation" stimmt so nicht - außerdem ist der dort angestellte Vergleich leider nutzlos - es fehlen die als "nicht mehr relevant" ausgewiesenen Ergebnisse, um ein vollständiges und damit nachvollziehbares bzw. überprüfbares Ergebnis für Außenstehende zu ermöglichen. So kann das Urteil dieses Vergleiches leider nur lauten:
Wie sie sehen, sehen sie Nichts!
Hinweis: Szenario 4 . . .
Es stellt sich nämlich hierbei für mich die Frage: Brauche ich das zusätzliche Programm überhaupt???

@amigafan: mit dem Ziel etwas Brauchbares fürs Team zu geben habe ich eine Bitte an Dich: in wie fern passt das Ergebnis oder meine Interpretation nicht. Versteh mich nicht falsch, aber ich möchte keine nutzlosen Erkenntnisse heben. Hol mich mal ab. Danke.

 

[Amigafan]

Fakt ist - die Kernzuweisung ist kontraproduktiv, d. h.:
Windows ermöglicht jedem Programm, jeden möglichen Kern einer CPU zu nutzen. Wenn man beginnt, dem Task-Scheduler mit einer Reduzierung auf bestimmte Kerne "dazwischenzupfuschen", erreicht man höchstens eine Verschlechterung der Ausgangslage. Dieses wäre Dir spätestens dann aufgefallen, wenn Du die bei Dir als "nicht mehr relevanten" Ergebnisse festgestellt hättest - es wäre darauf hinausgelaufen, dass mit einer manuellen Festlegung von Threads - egal ob single- oder multicore-fähig - kein besseres Ergebnis zustande kommt, als wenn man keine Kerne zuweist. Dieses zeigen zumindest die Ergebnisse, die ich festgestellt habe - und zwar auch mit der GIX 980 Ti.
Um es verständlicher zu machen:
Eine höhere Priorität des FahCores kann hilfreich sein, eine manuelle Kernzuweisung jedweden Prozesses dagegen nicht.
Denn - ich habe das Gefühl, dass hier von völlig falschen Tatsachen ausgegangen wird:
Ein Thread, der als Single-Core-Thread programmiert wurde, läuft als Single-Core - egal, wieviele CPU-Kerne zugewiesen werden. Er wird dadurch nicht schneller abgearbeitet.
Dagegen nutzt ein Multi-Core-Threads auch mehr als einen CPU-Core - aber niemals mehr, als die Anzahl der Threads, für die er programmiert wurde.
Als Beispiel:
Ist ein Programm auf die Nutzung von 4 Threads programmiert, helfen keine 6 CPU-Cores, um das Programm schneller abzuarbeiten - es werden nur 4 genutzt!
Daher ist - sowohl bei Single- als auch bei Multi-Core-Programmen für die Geschwindigkeit die CPU-Core-Architektur und die Taktfrequenz maßgebend. Den "Rest" besorgt der Windows Task-Scheduler . . .

 

[XeT]

Also ich sag mal das nicht alles behandelt wurde stimmt, das sieht man ja an den nicht relevanten.
Aber der Grund dafür ist in meinen Augen in Ordnung. Denn es geht um das CPU-Limit und ob OC oder smt/kerne etwas bringen. Nicht wie man es perfekt aufstellt. Mir sagt der Thread genau das was ich brauche. Mit etwas OC reicht mein Pentium um nicht die 980 zu limitieren.

 

[brooker]

Fakt ist - die Kernzuweisung ist kontraproduktiv, d. h.:
Windows ermöglicht jedem Programm, jeden möglichen Kern einer CPU zu nutzen. Wenn man beginnt, dem Task-Scheduler mit einer Reduzierung auf bestimmte Kerne "dazwischenzupfuschen", erreicht man höchstens eine Verschlechterung der Ausgangslage. Dieses wäre Dir spätestens dann aufgefallen, wenn Du die bei Dir als "nicht mehr relevanten" Ergebnisse festgestellt hättest - es wäre darauf hinausgelaufen, dass mit einer manuellen Festlegung von Threads - egal ob single- oder multicore-fähig - kein besseres Ergebnis zustande kommt, als wenn man keine Kerne zuweist. Dieses zeigen zumindest die Ergebnisse, die ich festgestellt habe - und zwar auch mit der GIX 980 Ti.
Um es verständlicher zu machen:
Eine höhere Priorität des FahCores kann hilfreich sein, eine manuelle Kernzuweisung jedweden Prozesses dagegen nicht.
Denn - ich habe das Gefühl, dass hier von völlig falschen Tatsachen ausgegangen wird:
Ein Thread, der als Single-Core-Thread programmiert wurde, läuft als Single-Core - egal, wieviele CPU-Kerne zugewiesen werden. Er wird dadurch nicht schneller abgearbeitet.
Dagegen nutzt ein Multi-Core-Threads auch mehr als einen CPU-Core - aber niemals mehr, als die Anzahl der Threads, für die er programmiert wurde.
Als Beispiel:
Ist ein Programm auf die Nutzung von 4 Threads programmiert, helfen keine 6 CPU-Cores, um das Programm schneller abzuarbeiten - es werden nur 4 genutzt!
Daher ist - sowohl bei Single- als auch bei Multi-Core-Programmen für die Geschwindigkeit die CPU-Core-Architektur und die Taktfrequenz maßgebend. Den "Rest" besorgt der Windows Task-Scheduler . . .

Ok, verstehe was Du meinst und kann Dir zu Teilen auch zustimmen.

1. Windows am besten allein managen lassen, bis auf Priorisierungen. Sehe ich ganz genauso. Aber, in dem Test wollte ich u.a. ermitteln, ob Multi-Threading was bringt. Nur aus diesem Grund habe ich unterschiedliche Anzahlen von Threads erzwungen.

2. Leider geben die Messergebnisse nicht zu 100% wieder, dass ohne eine Zuweisung die besten Ergebnisse (kleinste TPF) erreicht wird. Daher konnte ich das nicht als Ergebnis präsentieren.

3. Ohne Zuweisung habe ich in sofern als nicht mehr relevant angesehen, weil die Zuweisung von mehr als 2 Threads keine Verbesserung mehr brachte.

Ich denke inhaltlich sind wir nicht wirklich auseinander. Wie müsste meine Interpretation der Ergebnisse denn Deiner Meinung lauten bzw. was ist strittig und sollte geändert werden?

 

[brooker]

... neues zum Thema AM1: das CPU OC ist für das CPU falten stabil. Kommt die GPU dazu, stürzt alles ab. Der PCIe gibt zu wenig Strom raus. Also, Riser mit Spannungsversorgung eingesetzt und mit externer Spannung unterstützt. Läuft.


1 0x18 9413 08:43 92.885PPD 110 W 25%
2 0x18
3 0x18
4 0x18
5 0x18
Mittelwert 87.363 110 25

Sieht ja schon was freundlichen aus, wie mit dem kleinen Falter.