Allgemeiner Plauderchat über das Thema DC Part IV

@Outlaw9876
Danke für den Tip. Das Programm werde ich mir auf alle Fälle ansehen.
 
Die Sonne lacht, nimm Blende acht.
Und schalte alle Ryzen ein, es kann auch mal für SiDock sein. :D
Doppelposting wurde automatisch zusammengeführt:

Das passt doch wie Faust aufs Auge: Solar liefert 300 Watt und Rechner verbrauchen 310 Watt.
Doppelposting wurde automatisch zusammengeführt:

Aktuell sogar 350 Watt, wovon 335 verbraucht werden, weil meine GPUs noch ein wenig OPNG crunchen.
Die Update.bat scheint doch was zu helfen.
Doppelposting wurde automatisch zusammengeführt:

So, für heute wars das mit der Sonne, aber 1,655 kWh sind ja auch nicht übel. Für insgesamt 40 Wuzen SiDock und noch einige OPNG hat es gereicht. Mal sehen, was morgen ist.
1643382652975.png
 
Zuletzt bearbeitet:
Thanx for showing
 
Hat jemand auch die Herausforderung, dass die OPNG, seit es längerlaufende WUs sind, die auf einer 280X laufen,nicht fertig werden ? egal welches Windows? hab schon alles probiert. betrifft FX 8350 mit 990X Chipsatz. Jetzt teste ich sogar zwei 280X nur eine WU. Als die noch kürzer waren brauchten die ca. 15 Minuten. Alles OK. Erst seit die länger laufen spinnen die rum. Auf meiner 290X laufen die normal ca. 25 Minuten. Auf 280X hab ich sie nach 8 Stunden abgebrochen. Null last. Hat jemand eine Idee ? getestet: Win 7, Win 8, Win 8.1, Win 10. nur nachktes OS mit allen Updates und Boinc, mit verschiedenen Grafiktreibern. Ich glaube fast, es liegt an den WUs.
 
Ist bei mir auf Vega 64 auch passiert. Das ist ein Rechner, auf dem ich nur gelegentlich schaue; da standen die WUs teilweise bei 20 h. BOINC zu und wieder auf, dann liefen die WUs weiter und der Timer stand bei 15 Minuten. Die bleiben hängen und werden alleine nicht. Liegt also nicht spezifisch an deinem Rechner. Schön für mich zu wissen, dass ich auch nicht allein damit bin :-)
 
ok ich teste grad 2 WUs pro Graka. Mal sehen was passiert.
 
Hab zum Glück Linux in Benutzung und Nvidia für OPNG.
Früher war das mal bei Einstein so, dass man die WUs kurz pausieren musste, wenn sie hingen.
 
ok ich teste grad 2 WUs pro Graka. Mal sehen was passiert.
Ach so, ist bei mir erst seit etwa Sonntag aufgetreten. Davor lief es eine Woche ganz hervorragend. Hab daher auch die Wus selbst im Verdacht. War auch ein Win-Rechner!
 
Bei mir siehts grad so aus. *motz*

So nach pausieren und fortsetzen, alles wieder auf Null. OK dann wart ich mal mit OPNG ne Weile.
 

Anhänge

  • haengende_Wus.JPG
    haengende_Wus.JPG
    45,9 KB · Aufrufe: 6
Kann es sein dass die Cosmology WUs unter Windows ein ziemliches Problem haben wenn ein zweiter Thread pro Kern/Modul läuftund sich dann gern mal festfressen?
Das Problem hatte ich sowohl bei einem FX-8800P, als auch bei einem 3950x mit SMT. Unter Linux trat das Problem meines erachtens nicht auf. Hinzu kommt noch das vor allem der 3950x dann fast unbenutzbar war weil der Rechner dann nur noch stark verzögert reagierte, beim FX war der Effekt nicht so stark.
 
Kann es sein dass die Cosmology WUs unter Windows ein ziemliches Problem haben wenn ein zweiter Thread pro Kern/Modul läuftund sich dann gern mal festfressen?
Das Problem hatte ich sowohl bei einem FX-8800P, als auch bei einem 3950x mit SMT. Unter Linux trat das Problem meines erachtens nicht auf. Hinzu kommt noch das vor allem der 3950x dann fast unbenutzbar war weil der Rechner dann nur noch stark verzögert reagierte, beim FX war der Effekt nicht so stark.
Gleicher Effekt bei mir, ebenfalls 3950X. Ich nehme an, Du meinst die VirtualBox Multi-threaded WUs:
- fressen sich bei mir auch häufig fest (starting later) und laufen erst weiter, wenn ich den BM neu starte
- Rechner wird teilweise unbenutzbar, auch dann, wenn nicht alle Threads ausgelastet sind
 
Exakt, es geht um die VBOX WUs und die lassen sich bei mir unter Windows nur mit einem Thread pro Kern/Modul vernünftig berechnen weil sie sich sonst gern als "unmanageable" für die nächsten 24 Stunden verabschieden. Ich gehe davon aus das dieser Effekt auf die starke Reaktionsverzögerung des Systems zurückzuführen ist die bei mir unter Windows erheblich stärker als bei Linux (Ubuntu) ausfällt.
 
Ein Thread pro Kern heißt SMT off oder dass nur 16/32 Threads benutzt werden dürfen?
 
Unter Windows gibt es mit den VBox-Wus einen relativ großen Overhead bei der CPU-Auslastung.
Auf meinem 4700U 8C laufen 3 WUs mit je 2 Kernen und laut Taskmanager ist die CPU-Last bei 90%.
Da bleibt manchmal eine WU für 24 Stunden hängen (die wird dann Abgebrochen).
Stell ich auf 4 WUs mit je 2 Kernen dann hängen fast alle.
Die VBox-WUs skalieren auch relativ schlecht mit der Anzahl der Kerne.

Auf dem 4700U mit Linux laufen 4 WUs mit je 2 Kernen ohne Probleme.
 
@eiernacken1983
Das kommt zwar normalerweise aus Gleiche raus aber ich hatte auch schon erlebt das bei 50% dennoch beide Threads einzelner Kerne genutzt wurden und entsprechend viele Kerne dann ungenutzt blieben. Dabei kam es dann auch immer mal wieder zu den besagten Hängern der WUs. Bei den Bulldozer Modulen reichten bisher die 50%.
 
Kann es sein dass die Cosmology WUs unter Windows ein ziemliches Problem haben wenn ein zweiter Thread pro Kern/Modul läuftund sich dann gern mal festfressen?

Ich rechne ausschließlich unter Linux. Gehäuft in den letzten Tagen habe ich auch dort vereinzelt VM-WUs, die sich festfressen. Vom Anteil her sind die WUs bei rund 0,2%. Blöd nur, dass der Client keine neuen WUs lädt, wenn auch nur eine festhängt und auf später verschoben wird.
 
Hab mit der nativen Anwendung camb_legacy v2.17 windows_intelx86 unter Windows keinen einzigen Fehler. Warum nehmt ihr die VM-WUs?
 
Die geben letztendlich mehr Credit, auch wenn nur weniger Threads ausgelastet sind.
Die legacy bringen kaum mal mehr als 1000 Credit pro Thread pro Tag, die vBox WUs aber über 2000.
Da muss man dann die Balance finden, wo es gerade richtig läuft, nicht hängen bleibt und trotzdem mehr abwirft als legacy. Ein paar Threads bleiben ja dann noch frei, die kann man für andere Projekte einsetzen die im Idealfall unter Schonkost fallen, also nicht nochmal VMs brauchen oder riesige Caches usw...
 
Die geben letztendlich mehr Credit, auch wenn nur weniger Threads ausgelastet sind.
Die legacy bringen kaum mal mehr als 1000 Credit pro Thread pro Tag, die vBox WUs aber über 2000.
Da muss man dann die Balance finden, wo es gerade richtig läuft, nicht hängen bleibt und trotzdem mehr abwirft als legacy. Ein paar Threads bleiben ja dann noch frei, die kann man für andere Projekte einsetzen die im Idealfall unter Schonkost fallen, also nicht nochmal VMs brauchen oder riesige Caches usw...
TN Grid ist aus meiner Sicht so ein Schonkostprojekt, dafür aber mit medizinischem Hintergrund, falls sich hier jemand beeinflussen lassen möchte. Meine MW WUs sind 1-2 Sekunden schneller (also 45-47 statt 47-49) , wenn ich TN Grid statt SiDock am Start habe.
 
Hat jemand schon die neuen Sprot_delta-WUs bei SiDock in Arbeit?
Ich bekomme noch die Eprot.
1644587187941.png
Sind das auch Langläufer?
 
Nicht schlecht für einen N2. Der scheint auch sonst ganz gut unterwegs zu sein.
 
Heute Nacht gabs die mal kurzzeitig. Seit heute früh wird aber wieder Eprot ausgeschenkt. Macht aus meiner Sicht auch Sinn, das erstmal abzuschließen. Laufzeit der delta-Dinger auf Zen2 war 1000 - 3000 Sekunden.
 
Zuletzt bearbeitet:
Zurück
Oben Unten