Coronavirus -> folding@home

[Landjunge]

Die 114xx lasten schlechter aus als die 117xx WU's. Kann ich auf meiner HD7950 beobachten.

 

[MagicEye04]

Ich denke, jetzt weiß ich auch, warum der Rechner abgeschmiert ist. Die TDP-Begrenzung von amdgpu-utils funktioniert schlicht nicht.
Bei 1,8GHz gibt es immer mal Spitzen weit über 200W trotz eingestellter 120W. Das ist bei einem 400W-Netzteil nicht so gesund.
Also doch wieder fixe 1,7GHz.

 

[Berniyh]

Ja, da laufen auf 15 Threads Rosettas, aber die permanent.
Mir ging es darum, dass FAH mit manchen WUs die GPU sehr gut auslastet und mit anderen nur mäßig.

Gerade eben wollte ich noch mal nach dem Rechner schauen, da hatte er sich bereits aufgehängt. :/

Diesmal habe ich gleich FAHClient' im Verzeichnis /etc/init.d gestartet. Auf diese Weise nimmt er sich zwar die Userdaten, die abgespeichert sind - aber dieser client findet dann wiederum die GPU nicht. Also wieder beendet und den in /usr/bin gestartet. Das scheinen wohl 2 verschiedene Programme zu sein.

Ich mag diese Init Scripte eh nicht. Viel zu undurchschaubar. Aber du brauchst das auch wirklich nicht um FAH zu starten, kannst auch einfach eine simple systemd Unit schreiben. Ist in meinen Augen wesentlich übersichtlicher und das Ergebnis ist das Gleiche (oder hoffentlich in deinem Fall besser), da das Init Skript auch nur über Rückwärtskompatibilität von systemd mit dem längst toten SysVInit ausgeführt wird

Bei Arch (das läuft auf meinem Gaming PC der derzeit noch ein bisschen cruncht, wenn ich nicht zocke) wurde zum Glück schon was mitgeliefert:

[Unit]
Description=Folding@home distributed computing client
After=network.target

[Service]
Type=simple
WorkingDirectory=/opt/fah
ExecStart=/opt/fah/FAHClient --config /opt/fah/config.xml --exec-directory=/opt/fah --data-directory=/opt/fah

[Install]
WantedBy=multi-user.target

Erstelle einfach eine neue Datei /etc/systemd/system/foldingathome.service und füg den Inhalt da ein, wobei du natürlich noch die Pfade anpassen musst.
Unter Arch wird halt FAH in /opt installiert, aber das kann bei anderen Distributionen anders sein. Im Zweifelsfall einfach die Dateiliste von FAH durchschauen.
(Falls es dich interessiert kann ich auch noch ein paar Zeilen dazu schreiben was da drin steht.)
Starten/beenden von FAH danach mit

systemctl start/stop foldingathome.service

bzw. wenn du willst dass es beim Systemstart immer (oder nicht mehr) startet:

systemctl enable/disable foldingathome.service

Ich denke, jetzt weiß ich auch, warum der Rechner abgeschmiert ist. Die TDP-Begrenzung von amdgpu-utils funktioniert schlicht nicht.
Bei 1,8GHz gibt es immer mal Spitzen weit über 200W trotz eingestellter 120W. Das ist bei einem 400W-Netzteil nicht so gesund.
Also doch wieder fixe 1,7GHz.

hm, amdgpu-utils kenne ich nicht. Für das Undervolting nutze ich amdgpu-clocks.
Aber letztendlich ist das alles eine Funktionalität des Kernels und es geht auch komplett ohne irgendwelche Tools (amdgpu-clocks ist letztendlich auch nur ein Shell Skript das das etwas automatisiert).

Das Power Limit ist eigentlich eine Funktion des Hardware Monitoring Treibers für amdgpu.
Die Einstellungen dazu finden sich in

/sys/class/drm/card0/device/hwmon/hwmon5/power1_cap

wobei die Ziffern unterschiedlich sein können (z.B. card1, wenn du zwei GPUs hast und bei hwmon hängt es davon ab das wievielte Device für das Monitoring das ist).
In die Datei kann man das gewünschte Power Limit in Mikro(!)watt eintragen, also z.B. für deine 120 W:

echo 120000000 > /sys/class/drm/card0/device/hwmon/hwmon5/power1_cap

Funktioniert bei mir auch wunderbar:

amdgpu-pci-0c00
Adapter: PCI adapter
vddgfx:      1000.00 mV 
fan1:        1274 RPM  (min =  300 RPM, max = 3300 RPM)
edge:         +63.0°C  (crit = +85.0°C, hyst = -273.1°C)
                       (emerg = +90.0°C)
junction:     +70.0°C  (crit = +105.0°C, hyst = -273.1°C)
                       (emerg = +110.0°C)
mem:          +64.0°C  (crit = +95.0°C, hyst = -273.1°C)
                       (emerg = +100.0°C)
power1:      120.00 W  (cap = 120.00 W)

Mit 190W eingestellt (so habe ich die Kiste aktuell laufen ist die Sensorausgabe dann:

amdgpu-pci-0c00
Adapter: PCI adapter
vddgfx:        1.04 V  
fan1:        1490 RPM  (min =  300 RPM, max = 3300 RPM)
edge:         +70.0°C  (crit = +85.0°C, hyst = -273.1°C)
                       (emerg = +90.0°C)
junction:     +81.0°C  (crit = +105.0°C, hyst = -273.1°C)
                       (emerg = +110.0°C)
mem:          +72.0°C  (crit = +95.0°C, hyst = -273.1°C)
                       (emerg = +100.0°C)
power1:      188.00 W  (cap = 190.00 W)

Ist natürlich etwas umständlich das händisch zu machen und dafür sind eben die Tools da. Die sollten auch genau das tun.
Also einfach mal prüfen ob das der Fall ist und im Zweifelsfall auf ein anderes Tool wechseln.

 

[MagicEye04]

Das Starten klappt jetzt, ich muss halt die Version in usr/bin nehmen und die config aus meinem Home-Verzeichnis.
Dienste möchte ich nicht, das soll bei Bedarf manuell gestartet werden.

Ich denke mal, die Tools werden im Hintergrund alle das Gleiche machen. Also die TDP wird schon so in die "Karte" geschrieben. Aber es ist ja letztendlich ein Durchschnittswert und kurze Spitzen werden dabei nicht abgefangen.
Bis /sys/class/drm/card0/device/ komme ich noch in der Verzeichnisstruktur, dann ist Schluss, endloses Laden.

Wie genau erzeugst Du die Sensorausgabe amdgpu-pci-0c00 ?
Ist das von amdgpu-clocks ?
Dann werde ich mir das bei Gelegenheit mal anschauen.

 

[Berniyh]

Das Starten klappt jetzt, ich muss halt die Version in usr/bin nehmen und die config aus meinem Home-Verzeichnis.
Dienste möchte ich nicht, das soll bei Bedarf manuell gestartet werden.

Geht mit dem Dienst ja auch per start/stop. Gibt auch diverse GUIs dafür, wobei ich persönlich die nicht nutze.
Aber ich möchte so wie du auch nicht, dass das automatisch startet, deshalb mache ich das manuell per systemctl start foldingathome.service.

Ich denke mal, die Tools werden im Hintergrund alle das Gleiche machen. Also die TDP wird schon so in die "Karte" geschrieben. Aber es ist ja letztendlich ein Durchschnittswert und kurze Spitzen werden dabei nicht abgefangen.

hm, ne bei mir nicht. Ich hab bislang nicht einmal beobachtet, dass das Limit überschritten wurde.

Bis /sys/class/drm/card0/device/ komme ich noch in der Verzeichnisstruktur, dann ist Schluss, endloses Laden.

hm, komisch. Probier es mal mit sudo oder als root. Sollte aber eigentlich (lesend) auch als normaler Nutzer gehen, zumindest hier ist das der Fall.
Könnte aber sein, dass da Tools wie selinux o.ä. dazwischen funken. Manche Distributionen haben sowas ja angeschalten.

Wie genau erzeugst Du die Sensorausgabe amdgpu-pci-0c00 ?
Ist das von amdgpu-clocks ?
Dann werde ich mir das bei Gelegenheit mal anschauen.

amdgpu-clocks ist wirklich nur ein Skript das die Werte in die richtigen Dateien schreibt.
Die Sensorausgabe kommt vom lm_sensors Befehl sensors. bzw. man kann das auf einen Sensortyp beschränken, z.B.:

sensors amdgpu-pci-0c00

gibt dann aus

amdgpu-pci-0c00
Adapter: PCI adapter
vddgfx:        1.08 V  
fan1:        1261 RPM  (min =  300 RPM, max = 3300 RPM)
edge:         +60.0°C  (crit = +85.0°C, hyst = -273.1°C)
                       (emerg = +90.0°C)
junction:     +69.0°C  (crit = +105.0°C, hyst = -273.1°C)
                       (emerg = +110.0°C)
mem:          +63.0°C  (crit = +95.0°C, hyst = -273.1°C)
                       (emerg = +100.0°C)
power1:      167.00 W  (cap = 190.00 W)

Oder für die CPU:

sensors k10temp-pci-00c3

Ausgabe:

Adapter: PCI adapter
Vcore:       950.00 mV 
Vsoc:          1.09 V  
Tdie:         +45.2°C  
Tctl:         +45.2°C  
Tccd1:        +46.8°C  
Icore:         7.00 A  
Isoc:          9.50 A

Gib einfach mal im Terminal den Befehl sensors ein.

Im Grunde ist das einfach nur die "Billigvariante" von den graphischen Monitoringtools, aber es ist halt auch das was beim eigentlichen Monitoringpaket lm_sensors mitgeliefert wird auf das der ganze Rest aufbaut. Also quasi das "offizielle" Tool.
Wenn dort das Power Limit richtig angezeigt wird, dann sollte es auch greifen.

Wenn du die Ausgabe von sensors mal eine Weile beobachten willst, dann gib ein:

watch -n 0.5 sensors amdgpu-pci-0c00

Wobei die Zahl nach -n für das Abfrageintervall in Sekunden steht. Bei mir sehe ich da auch mit 0.1s Auflösung nicht, dass das Limit signifikant überschritten wird.
(wenige W evtl. aber definitiv nicht mehr als 5%).

 

[MagicEye04]

OK, sensors kenn ich.

Das kommt bei mir für die Karte raus - zufälligerweise incl. TDP-Überschreitung:

magiceye04@Zen:~$ sensors amdgpu-pci-2900
amdgpu-pci-2900
Adapter: PCI adapter
vddgfx:       +0.93 V  
fan1:        1984 RPM  (min =    0 RPM, max = 3850 RPM)
temp1:        +65.0°C  (crit = +118.0°C, hyst = -273.1°C)
power1:      154.00 W  (cap = 120.00 W)

Mehr gibts leider nicht.

Aber ich denke, das passt jetzt soweit alles.

 

[denjo]

5700xt@110W bei 1,6 ghz

so hält sich der stromverbrauch noch in grenzen aber die 10 mio. mach ich voll ^^

 

[Berniyh]

OK, sensors kenn ich.

Das kommt bei mir für die Karte raus - zufälligerweise incl. TDP-Überschreitung:

magiceye04@Zen:~$ sensors amdgpu-pci-2900
amdgpu-pci-2900
Adapter: PCI adapter
vddgfx:       +0.93 V  
fan1:        1984 RPM  (min =    0 RPM, max = 3850 RPM)
temp1:        +65.0°C  (crit = +118.0°C, hyst = -273.1°C)
power1:      154.00 W  (cap = 120.00 W)

Mehr gibts leider nicht.

Aber ich denke, das passt jetzt soweit alles.

hm ok, das ist weird. Muss sich um einen Bug handeln.
Oder evtl. ist dein Kernel etwas älter und daher wird das noch nicht so gut unterstützt, keine Ahnung.

 

[Berniyh]

@MagicEye04: hab gestern noch was vergessen was evtl. auch interessant für dich ist:

root@draco:~ $ cat /sys/kernel/debug/dri/0/amdgpu_pm_info 
Clock Gating Flags Mask: 0x30fe9fcf
        Graphics Medium Grain Clock Gating: On
        Graphics Medium Grain memory Light Sleep: On
        Graphics Coarse Grain Clock Gating: On
        Graphics Coarse Grain memory Light Sleep: On
        Graphics Coarse Grain Tree Shader Clock Gating: Off
        Graphics Coarse Grain Tree Shader Light Sleep: Off
        Graphics Command Processor Light Sleep: On
        Graphics Run List Controller Light Sleep: On
        Graphics 3D Coarse Grain Clock Gating: On
        Graphics 3D Coarse Grain memory Light Sleep: On
        Memory Controller Light Sleep: On
        Memory Controller Medium Grain Clock Gating: On
        System Direct Memory Access Light Sleep: On
        System Direct Memory Access Medium Grain Clock Gating: On
        Bus Interface Medium Grain Clock Gating: On
        Bus Interface Light Sleep: On
        Unified Video Decoder Medium Grain Clock Gating: Off
        Video Compression Engine Medium Grain Clock Gating: Off
        Host Data Path Light Sleep: On
        Host Data Path Medium Grain Clock Gating: Off
        Digital Right Management Medium Grain Clock Gating: On
        Digital Right Management Light Sleep: On
        Rom Medium Grain Clock Gating: On
        Data Fabric Medium Grain Clock Gating: On
        Address Translation Hub Medium Grain Clock Gating: On
        Address Translation Hub Light Sleep: On

GFX Clocks and Power:
        945 MHz (MCLK)
        1594 MHz (SCLK)
        1138 MHz (PSTATE_SCLK)
        800 MHz (PSTATE_MCLK)
        1081 mV (VDDGFX)
        155.0 W (average GPU)

GPU Temperature: 63 C
GPU Load: 92 %

SMC Feature Mask: 0x000000001ba1fb4f
UVD: Disabled

VCE: Disabled

Aus der Datei kann man als Gegencheck zur Ausgabe des sensors auch noch mal die Leistung ausgeben lassen und zudem auch noch die Last auf der GPU.
Ich würde aber dringend davon abraten dich eingehend mit den anderen Dateien in dem Verzeichnis zu beschäftigen, alleine das Auslesen kann schon zu einem Lockup der GPU führen.
Die angegebene Datei ist aber safe.

 

[Hotstepper]

Die einen bekommen keine WUs, die anderen werden sie nicht wieder los.

19:29:31:WU00:FS01:Upload 7.45%
19:29:37:WU00:FS01:Upload 18.38%
19:29:43:WU00:FS01:Upload 30.81%
19:29:49:WU00:FS01:Upload 44.72%
19:29:55:WU00:FS01:Upload 57.14%
19:30:01:WU00:FS01:Upload 70.55%
19:30:07:WU00:FS01:Upload 83.97%
19:30:13:WU00:FS01:Upload 93.41%
19:30:16:WU00:FS01:Upload complete
19:30:16:WU00:FS01:Server responded PLEASE_WAIT (464)
19:30:16:WARNING:WU00:FS01:Failed to send results, will try again later

So geht das schon den ganzen Tag

 

[thorsam]

F@H ist eigentlich mein Hausprojekt. Im Augenblick mache ich aber einen Bogen drumrum,
weil Amazon, Google und Co. ihre Rechenzentren für F@H laufen lassen.
Ich denke meine lächerlichen 12 Mio. PPD machen den Kohl nicht fett.

 

[Landjunge]

Sobald GPUGrid da was rausbringt bin ich auch bei F@H weg. Meine alten Radeons machen zusammen lächerliche 400K PPD. Und die 660Ti glüht schonmal GPUGrid vor.

 

[koschi]

GPUGrid würden einen Ansturm weiterer Nutzer garnicht aushalten, deren Anbindung und Server pfeift so schon oft aus dem letzten Loch.

Meine AMD ist aktuell gerade idle, sie hat wohl über den Tag auch einige WUs geschafft, noch kein Grund zur Panik.
Die kleine Nvidia hat allerding eine dicke WU mit 5.000.000 Steps am Wickel, ich bin mal gespannt wie lange die dauert.

 

[koschi]

https://foldingathome.org/2020/04/1...h-the-option-to-prioritize-covid-19-projects/

NEW FOLDING@HOME SOFTWARE WITH THE OPTION TO PRIORITIZE COVID-19 PROJECTS
April 17, 2020
by Greg Bowman

In response to popular demand, we have created an update to the Folding@home software that allows you to prioritize COVID-19 projects. We encourage you to upgrade as the new software includes important bug fixes and security updates. Downloads are available here. Please also join me in thanking the Center for the Science and Engineering of Living Systems (CSELS) at Washington University in St. Louis for funding the development of this software update.

Our top priority for this release was to add the COVID-19 option as quickly as possible. We also took the opportunity to fix many of the issues raised by our volunteers, but did not address those that would have caused significant delays in the release of the new software. To better address important bugs in the future, we’ve organized a team of volunteer developers who are sorting through and prioritizing our issue tracker on GitHub. They are already making huge strides.

Looking towards the future, we are also working on a new Open-Source Folding@home software. This new software will improve the performance of Folding@home and make it easier to get the community involved in its development. By tapping into the massive amount of technical talent available in the Folding@home community, we believe we can produce better software with a more engaging and productive user experience and update that software more often. More information about the availability of this new software will soon be announced on this blog.

Scheint die altbackene Software könnte eine Überarbeitung erfahren, wunderbar!

--- Update ---



--- Update ---

Falls jemand cli only unterwegs ist, die config.xml Option heißt:
<cause v='COVID_19'/>

 

[Krümel]

Ich bekomme keine Covid 19 Wus

 

[Rekrut]

Ich bin froh, wenn ich überhaupt Wus bekomme! Für die GPU zieht er sich irgentwie gar keine mehr und für die CPU ist das mal so und mal so. Lässt ihr denn jetzt lieber über die Weboberfläche Rechnen, oder nutzt ihr eher das Programm? Im Programm selber kann man ja auch Themen anwählen, nur Covid 19 fählt dort in der Liste. Die lässt sich dann wahrscheinlich mit dem o.g. Befehl erweitern?!

 

[Krümel]

Hab jetzt eine bekommen für meine GPU.
Unter Win10 kann man in den "advanced control" mit der neuen Version vom Client auch Covid-19 einstellen.

 

[Rekrut]

Ich glaube der hat wieder irgend ein Problem mit der Grafikkarte, nun meint das Programm, dass die Grafikkarte nicht unterstützt wird. Gestern hatte die aber noch eine WU bekommen und erfolgreich durchgerechnet, nun bekommt die keine WUs mehr. Ich verstehe das nicht. Mein PPD steht momentan bei knapp 1,25 Mio laut Programm. Gestern waren das mit GPU 1,5 Mio, ist ja schon ein kleiner, aber guter Unterschied.

Weiß einer was ich da noch Probieren kann, um die GPU für FAH Schmackhaft zu machen? Oder ist eine RX 560 wirklich zu schlecht für FAH? FAH kann doch nicht so GPU Wählerisch sein. Ich habe aber auch gelesen, dass das FAH Programm so alt und in die Jahre gekommen sein soll, dass es viele moderne Linux Standards gar nicht unterstützt und deswegen GPU Probleme bereiten sollte.

Ich hatte allerdings auch schon gelegentlich Monster WUs für CPU erhalten, die auch schon 700.000- 800.000 PPD generieren können, dann bräuchte ich die GPU nicht, aber auch die bekomme ich nicht immer. meistens sind das ja die normalen, kleinen WUs, die dann weniger abwerfen.

Hab Client-type Advanced und bigadv schon probiert. Zurzeit habe ich client-type beta eingestellt.

 

[koschi]

Mein FAH läuft als root und erkennt damit die Nvidia und AMD GPU. Ich starte den Client alle 15min neu falls weniger als 2 WUs laufen, dann gibt es idr fix Nachschub.

 

[Landjunge]

@ Affe

hast du auch den Eintrag >next-unit-percentage< mit wert >90< schon probiert. Dann fängt er rechtzeitig an nach einer neuen WU zu fragen

 

[Rekrut]

Ich wollte die neue FAH Version installieren, danach wollte FAH gar nicht mehr starten. Ich glaube ich habe mittlerweile zu viel herumprobiert. Ich habe ein paar Hilfestellungen im FAH Forum ausprobiert, die nicht zum Erfolg geführt haben. Ich installiere am besten neu, dann ist alles wieder sauber und kann bei der AMD Karte mal den reinen OpenCL Treiber ausprobieren, ohne gleich den ganzen Treiber davon installieren zu müssen.

--- Update ---

Nach der Linux Neuinstallation läuft FAH wieder, allerdings natürlich ohne GPU, die muss ich mir wieder neu einrichten.

--- Update ---

Ich habe nun den Treiber installiert, der funktioniert wunderbar unter FAH: https://www.planet3dnow.de/vbulleti...tathlon-2020?p=5277247&viewfull=1#post5277247
Zumindest hat er die nun erkannt und sucht zurzeit nach WUs für GPU, die er zurzeit nicht findet.

Dann probierte ich noch das hier aus: https://rocm-documentation.readthedocs.io/en/latest/Installation_Guide/Installation-Guide.htm und https://foldingforum.org/viewtopic.php?f=81&t=33942 führte bei mir wiederum weniger zum Erfolg, nun weiß ich aber über diese Anleitungen, wie ich Benutzer in Gruppen hinzufügen kann

--- Update ---

Die GPU will doch nicht mehr unter FAH, in BOINC ist alles klar. Ich habe nun nochmal lange herumprobiert, sogar Ubuntu 18.04 nutzte ich, da ich dort die AMD Treiber besser installieren kann. Dafür kann ich meine o.g. Anleitung nicht mehr komplett nutzen. Unter Ubuntu sprich in FAH wird die Grafikkarte jedoch von anfang an richtig erkannt, also daran liegt es nicht. Warum die trotzdem nicht genutzt werden kann, ist für mich ein Rätsel.

--- Update ---

ach jetzt kann ich die wieder hinzufügen, indem ich den Service von FAH neu gestartet habe. Bekloppt.

--- Update ---

Nun versucht er die ganze Zeit für die GPU herunterzuladen und wenn er das mal geschafft hat, so kann er die WU auf der GPU nicht starten und bricht wieder ab. :/

--- Update ---

Alle WUs die an die IP:155.247.166.219 gesendet werden müssen, für die gibt es keine Verbindung zum Server, ich habe mitlerweile 5 Stück fertig und können nicht gesendet werden.

 

[Berniyh]

rocm wird mit einer 580 glaube ich nicht funktionieren (oder nicht gut).

Am Besten den OpenCL Teil des amdgpu-pro Treibers installieren. Es reicht der OpenCL Teil, der Rest darf (und sollte) ruhig Open Source sein.

Tatsächlich habe ich aber nach dem Upgrade auch Probleme mit meiner Vega 64. Vorher lief es problemlos, jetzt mag er aus irgendwelchen Gründen nicht mehr.
Obwohl sich außer einem SW Update von FAH nichts geändert hat.

 

[MagicEye04]

Ich glaube der hat wieder irgend ein Problem mit der Grafikkarte, nun meint das Programm, dass die Grafikkarte nicht unterstützt wird. Gestern hatte die aber noch eine WU bekommen und erfolgreich durchgerechnet, nun bekommt die keine WUs mehr. Ich verstehe das nicht.

Das hatte ich auch, also ich /usr/bin/FAHClient gestartet habe.
Mit dem FAHclient in ../init.d/ wird die GPU hingegen erkannt.

Heute ganze 2 WUs bekommen, gestern anscheinend maximal Eine.

Da kann ich ja doch beide GPUs rechnen lassen, wenn die die meiste Zeit im idle verbringen.

 

[koschi]

Freut mich dass mit meinem Paket die GPU erkannt wird, ROCm braucht es zusätzlich nicht mehr, das wäre eine weitere OpenCL Implementierung (wie auch Mesa Clover eine ist), mehrere auf einem Rechner vertragen sich nur bedingt.
Das init Skript startet den FAHClient unter einem anderen Benutzer, der kann wohl ohne weiteres nicht alle GPUs sehen. Bei mir wurde daher aus dem Test mit root ein andauerndes Provisorium. Ggf. müsste man den FAH User entsprechend berechtigen, das er die AMD GPU nutzen kann.

--- Update ---

@ Affe

hast du auch den Eintrag >next-unit-percentage< mit wert >90< schon probiert. Dann fängt er rechtzeitig an nach einer neuen WU zu fragen

Danke, den kannte ich noch nicht!

 

[Rekrut]

Ich hatte dem Fahclient die Gruppe video zugewiesen, damit der auf die GPU zugreifen kann, in der vorherigen Version ging das.
Mit dem opencl von sompe erkannte er das weder in Boinc noch in Fah, warum auch immer. Aber auch mit ROCm klappte das nicht so, die AMD Treiber sind vor 2 Tagen ganz neu für Linux erschienen.

Ich bin nun einen anderen Weg eingeschlagen, unter Boinc funktioniert es ja und lasse dort in Einstein die GPU nutzen und die CPU in FAH, dann passt das ja
Allerdings schrumpft dann der PPD von 600.000 auf 400.000, da die GPU 4 Instanzen in Boinc aufmacht für 4 WUs gleichzeitig. Damit geht die Leistung in FAH etwas runter. Oder das liegt wieder an den Bonuspunkten, da ich für BOINC kurz auf Pause gedrückt habe.

Mit der neuen WU schwangt er zwischen 450.000 - 500.000 PPD das geht ja noch. Mit den beiden PCs sind es immer noch 1,2 Mio am Tag.