[Sammelthread] Der Serverwahn

[Bumblebee]

You've got a awesome PC!

... seconded.. - Happy folding, Bro

 

[nfsgame]

Nice one . This topic is used to show the Folding-PCs of the users . You don't have to start a new topic .
Happy folding!

 

[Wolvie]

A real powerful and pretty system.
~ 400-500k PPD with one(!) system are damt crazy!

 

[mihapiha]

für die PPD ist sein System nicht mal so teuer. Man bedenke dass man die CPUs auch gebraucht für relative faire Preise bekommen kann, und dann entsteht so eine Leistung. Einfach genial

 

[davidof2001]

Mann muss sich nur mal vorstellen, was diese Maschine erst mit den 6272er Opterons veranstaltet.

 

[WOLF_TEAM_LEADER]

I paid $450 each for the 6174's brand NEW.
If anyone is deciding between 61xx and 62xx chips then here is what you should know.
A 16 core Bulldozer/Inter-Lagos 62xx has 1 FPU for every 2 cores, each being 256-bit.
A 12 core Magny-Cours 61xx has 1 FPU for every 1 core, each being 128-bit.
The 62xx chip has 4 decoders while the 61xx chip has 3 decoders.
So it's 48 cores & 48x 128-bit FPUs w/ 4x 3 decoders Vs. 64 cores & 32x 256-bit FPUs w/ 4x 4 decoders.
The greater amount of FPUs on the 61xx and the fact that 62xx chips large FPUs are being starved means there is an 'internal bottleneck' if you like within the CPU.
At least this is the case for Folders...

Therefore, 6174 > 6274 which I have seen true in my TPF results compared to fellow 4P folders.
61xx chips also consume quite a bit less power than 62xx chips so you got greater performance for less power consumption.
Only 61xx chips are currently supported for over clocking with the 3rd party BIOS.

 

[Muschkote]

Mann muss sich nur mal vorstellen, was diese Maschine erst mit den 6272er Opterons veranstaltet.

Ich kann die Erkenntnisse von WOLF_TEAM_LEADER bestätigen, die 6272er werden nicht schneller sein als die 6172er.
Wenn du mal auf Seite 1 in der Übersicht mein System (in dem Fall "nur" ein 2P Sys) mit einem 6272er vergleichst, wirst du sehen, dass mein Sys. mehr ppd bei gleichzeitig weniger "Stromverbrauch" liefert.

 

[Bumblebee]

Das ist alles schön und gut; bloss...

... sind 6172 und 6174 (noch) schwer(er) zu bekommen und sehr teuer - verglichen mit 6272 bzw. 6274
Man muss schon Glück haben (so wie ich mit dem SR2-System) um zu vernünftigen Preisen so ein System zusammenzustellen

 

[mihapiha]

oder man muss Kontakte in Amerika haben. In den USA wechseln die CPUs, verglichen mit unseren Preisen, relativ billig den Besitzer.

Wolf hat als Australier inportieren müssen. Auch in seinem Land sind die CPUs viel zu teuer.

 

[Thosch]

Btw ... Ist das "normal" das eine 6903 von 13:56 bis 15:15 UTC braucht um upzuloaden ...? Das is ne Menge Zeit und Punkte die verloren gehen ...

 

[Malkolm]

Es sind gute 220MB die da durch die Leitung gehen
Bei meiner 16000er Leitung (mit ~100KB/s Upload) dauerts auch 40 Minuten.

Abhilfe schafft da übrigens langouste.

 

[Wolvie]

Es sind gute 220MB die da durch die Leitung gehen
Bei meiner 16000er Leitung (mit ~100KB/s Upload) dauerts auch 40 Minuten.

Abhilfe schafft da übrigens langouste.

Gibt's dafür ne Anleitung? Bin auf der Suche... hab aber bis jetzt nix gefunden.

Und was ist eigentlich diese "thekraken"-Geschichte? Soweit ich gelesen hab ist das aber nur nützlich bei Multi Socket Systemen?

 

[Malkolm]

Für den Kraken schreibe ich gerade nen deutschen Guide, aber ja ist eigentlich nur für Multisockel geeignet. Habs bei meinem SB-E mal ausgetestet und konnte keine Veränderung feststellen was die TPF angeht (nur die normale Streuung von +- 20s).

Für langouste gibts schon anleitungen im netz (such mal nach tear + langouste oder fah + langouste). Das Tool ist vom gleichen Mitfalter wie auch TheKraken: Tear. Im Endeffekt setzt du dir damit einen lokalen Fah-Proxy auf, der das senden (und aufräumen, der Step der hier bei einigen 2h dauert!) übernimmt und dem client direkt die möglichkeit gibt die nächste WU zu saugen und zu beackern
Im Endeffekt spart man sich damit, je nach System und Leitung, bis zu mehreren Stunden pro BigBig-Wu.

Wenn der Kraken Guide ferig ist und gefällt kann ich das Gleiche auch nochmal für langouste machen.

 

[WOLF_TEAM_LEADER]

tear's The Kraken helps decrease TPF on anything with 2 or more sockets.
I was getting live support from Tear and some of the other big folders at [H] when I was building my 4P
If you are running a Dual Socket Intel then BFS is also recommended but if it's a dual or quad socket AMD then just The Kraken.
Single CPU rigs should not use the kraken.
I haven't installed langouste yet but I can record the time decreases it gives me afterwards.

BTW: What % of members would be able to read my posts? :S

 

[nfsgame]

BTW: What % of members would be able to read my posts? :S

I think (understand) English isn't a problem for our members . But we have to take care that there's not to much English - quote out of the board-rules (translated): "The board-language is german." .

 

[A.Meier-PS3]

Wenn ich das Ganze jetzt richtig verstanden habe, erweitern diese beiden Programme einfach den V6 um die UP/Dounwload-Geschichte des V7 das man wärend des Uploads der fertigen WU schon die nächste falten kann.

Also nur interessant für V6-Falter > Richtig?

 

[Wolvie]

[...]Wenn der Kraken Guide ferig ist und gefällt kann ich das Gleiche auch nochmal für langouste machen.

Danke für die tolle Erklärung.
Und ein Guide für "die" Langouste würde ich sehr nützlich finden

 

[Bumblebee]

BTW: What % of members would be able to read my posts? :S

Around 80% - i guess

Wenn ich das Ganze jetzt richtig verstanden habe, erweitern diese beiden Programme einfach den V6 um die UP/Dounwload-Geschichte des V7 das man wärend des Uploads der fertigen WU schon die nächste falten kann.

Also nur interessant für V6-Falter > Richtig?

Ausgezeichnete Frage - würde mich auch interessieren...

 

[Amigafan]

Wenn ich das Ganze jetzt richtig verstanden habe, erweitern diese beiden Programme einfach den V6 um die UP/Dounwload-Geschichte des V7 das man wärend des Uploads der fertigen WU schon die nächste falten kann.

Also nur interessant für V6-Falter > Richtig?

Richtig - in V7 hast Du ja die Möglichkeit, den Flag: next-unit-percentage zu setzen - damit kannst Du die nächste WU bereits vor Beendigung der "alten" WU herunterladen und damit die Wartezeit des Down-und Uploads "überbrücken" - denn der Upload findet während der Berechnung der neuen WU statt . . .

Daher ist langouste nur für diejenigen interessant, die unter Linux noch den V6er Clienten nutzen

 

[Malkolm]

Für Langouste stimmt das. Das Entkoppeln von Übertragungszeit und Rechenzeit erledigt das V7 Control-Center nativ schon vollkommen ausreichend. Ob der V7 Client alleine (also ohne ControlCenter) das ebenfalls beherrscht müsste man mal testen. Da es aber in meinen Augen unsinnig ist den V7 ohne ControlCenter zu nutzen ist das eigentlich auch unerheblich.

Der Kraken ist aber was vollkommen anderes. Um die Frage jetzt schon zu beantworten poste ich hier schonmal einen Auszug aus dem Guide:

Was genau macht dieser "Affinity Wraper"? (Für Interessierte)

Um zu verstehen wo die Optimierungen vom Kraken ansetzen muss man verstehen wie ein MultiSockel-System funktioniert. Ein solches besteht in der Regel aus mehreren Prozessoren, die jeweils eigenen L1/2/3-Cache besitzen und ebenfalls jeweils an einen Satz Arbeitsspeicher besonders schnell angebunden sind. Die Kommunikation der einzelnen Prozessoren untereinander und mit den restlichen Systemkomponenten erfolgt über einen Ringbus, der (nicht zuletzt aufgrund der langen physikalischen Wege) langsammer ist als die Kommunikationswege innerhalb einer CPU-RAM-Konfiguration. Ein Aufgabe wird von einem CPU-Gespann also dann besonders schnell erledigt, wenn diese Aufgabe in Häppchen geteilt wird, welche die einzelnen CPU-Kerne berechnen können, ohne dass sie zwischendurch aufeinander angewiesen sind. Je mehr Zeit damit verbracht wird auf andere Komponenten zu warten, desto weniger bleibt natürlich für die eigentliche Arbeit übrig -> Der Kern wartet -> Die Leistung sinkt.
Der SMP-Client von F@H macht sich natürlich die potentiell riesige Leistungsfähigeit von Mehrkern-Prozessoren zu Nutze und verteilt die WorkUnit soweit es geht in Häppchen, gibt diese aus und wartet auf die berechneten Teilergebnisse dieser "Worker" um daraus die nächsten Häppchen zu generieren und zu verteilen. Brauchen dabei aber nun einige Worker länger als andere müssen im schlimmsten Fall alle anderen Worker warten, bis die langsammen Aufgaben abgearbeitet sind -> die PPD sinken.

Dieses Problem des "Load-Balancings" gibt es natürlich auch bei einzelnen Mehrkernprozessoren, es wird aber natürlich umso problematischer, je mehr Kerne zur Verfügung stehen und je länger und langsammer die Kommunikationswege sind.
Für die Software selbst ist es übrigens unerheblich, ob die vorhandenen Kerne von einer CPU oder Mehreren zur Verfügung gestellt werden. Diese Aufteilung findet erst recht tief im Betriebssystem statt. Der Scheduler (deutsch: Der Planer, der Disponent) verteilt die einzelnen Worker-Threads auf die zur Verfügung stehenden Recheneinheiten. Diese Zuteilung kann sich zwischendurch sogar ändern, etwa wenn dadurch ein vorher stark belasteter Kern entastet und gleichzeitig ein wenig belasteter Kern besser ausgelastet wird.
Im Falle von F@H und Mehrsockel-Systemen arbeitet der Linux-Scheduler aber nicht optimal. Startet der FahCore seine Worker sichern sich diese direkt einige Bereiche des der CPU zugehörigen Arbeitsspeichers und arbeitet nunmehr nurnoch mit diesem. Kommt der Scheduler aber nun auf die Idee einen Worker-Thread auf eine andere CPU zu schieben, eben weil dies aus reiner Rechenzeitsicht evtl. gut wäre, so muss der Worker-Thread über den langsammen Ringbus mit "seinem" Arbeitsspeicher kommunizieren. Letztere Kommunikations-Verzögerungen wiegen schwerer als die Rechenzeitvorteile nach dem sich der Scheduler orientiert -> Die Leistung sinkt.

Der Kraken Optimiert nun den Faltprozess auf zwei Weisen:
Zum Einen behebt er das zuletzt geschilderte, suboptimale Scheduler-Vorgehen auf eine recht brachiale Weise, indem er sich sozusagen bei der Installation um (bereits vorhandene!) FahCores "wickelt". Wird ein solcher umwickelter FahCore gestartet (etwa durch den Client), schaltet sich der Kraken dazwischen und übernimmt die Steuerung des FahCores. Bereits in der Startphase des Cores setzt der Kraken die Zugehörigkeit gestarteter Worker-Threads zu einzelnen Kernen fest. Damit wird sichergestellt, dass ein Worker immer eine schnelle Anbindung zu "seinem" Speicher erhält und der Scheduler nicht mehr dazwischenfunken kann.
Zum Anderen bietet der Kraken die Möglichkeit den FahCore automatisch nach dem jeweils ersten erfolgreich durchlaufenen Speicherpunkt einer WU neu zu starten. Was ersteinmal widersinnig klingt hat folgenden Hintergrund: Auch Stanford kennt natürlich das Problem des Load-Balancings und hat seinen FahCores deshalb eine eigene Methode spendiert den Faltprozess zu optimieren, den Dynamic-Load-Balancer (DLB). Dieser springt theoretisch an, wenn die Verzögerung durch Wartezeiten der einzelnen Worker mehr als 5% beträgt, praktisch ist das Aktivieren des DLB aber mehr oder weniger zufällig. Die Erfahrung hat gezeigt, dass der DLB aber fast immer anspringt, wenn man den FahCore von einem Speicherpunkt fortführt, was der Kraken entsprechend zum frühstmöglichen Zeitpunkt eben genau so macht. Diese Optimierungsfunktion des Kraken ist im Übrigen optional.

Hoffe das hilft schonmal