WCG THOR Challenge 2020

Also im Bunker dürfen es bei mir schon gern mehr ARP sein als Kerne vorhanden sind. Um die gleichzeitig berechneten WUs einzuschränken, müsste ich vermutlich eine komplexe app_info.xml basteln. Dann lass ich das Limit lieber auf [Threadanzahl]*0,9 oder so.

So komplex ist das gar nicht:

app_config.xml
Code:
<app_config>
<app>
<name>arp1</name>
<max_concurrent>4</max_concurrent>
</app>
<app>
<name>opn1</name>
<max_concurrent>10</max_concurrent>
</app>
<app>
<name>ssc1</name>
<max_concurrent>8</max_concurrent>
</app>
  <project_max_concurrent>16</project_max_concurrent>
</app_config>

Dann wird jeweils nur die festgelegte Anzahl je Projekt, aber in der Summe max. 16 berechnet. Ist auch praktisch wenn man mit <ncpus> bunkern will/muss. Dann starten auf einem 8-Kerner nicht plötzlich 100 WUs gleichzeitig :)
Eben mal probiert, da es mich auch stört, wenn die krassen WUs paralell sich die Rechenressourcen wegnehmen. Dabei ist mir aufgefallen, dass dein Code bei SCC ins Leere läuft, da Du nen Schreibfehler drin hast: FALSCH: ssc1; RICHTIG: scc1
Danke, hätte mir eigentlich auffallen müssen. Boinc meckert in den Meldungen, wenn da falsche Bezeichnungen eingetragen sind.
 
Da mein großer Ripper über Nacht kaum einen Fortschritt mit seinen ARP WUs zeigte habe ich nun SMT abgeschaltet und schon geht es sichtbar besser voran. Kann es sein das diese WUs extrem RAM lastig sind und so das vergleichsweise schmale Speicherinterface zum Problem wird?
 
Hmm interessant der kleine Androide rechnet erst seit gestern Nachmittag und hat schon über 2 Tage Runtime *greater* *chatt*
Unbenannt2.png
 
Darum rechne ich nur OPN
 
Da mein großer Ripper über Nacht kaum einen Fortschritt mit seinen ARP WUs zeigte habe ich nun SMT abgeschaltet und schon geht es sichtbar besser voran. Kann es sein das diese WUs extrem RAM lastig sind und so das vergleichsweise schmale Speicherinterface zum Problem wird?
Irgendwer hier hatte geschrieben, das die ARPs sehr L3 Cache lastig sind. Bei mir waren es dann ab 12 Parallel ein starker anstieg der Laufzeit zu verzeichnen. Vorteil der ARPs ist halt, das man die gut Bunkern kann wegen den hohen Laufzeiten. WCC rückt ja kaum mehr als 1k WUs je Instanz raus.
 
@WhiteFire
Nun ja, da der L3 in den Chiplets sitzt wäre das im Vergleich zum 3950 kein wirkliches Problem aber klar, wenn der überläuft wandern die Daten in den RAM und dann wird die beim Ripper verhältnismäßig geringere Bandbreite über alle Threads hinweg zum Problem.
 
Und meinte nicht jemand, die SCCs würden mehr Credits abwerfen als die OPNs? Bei mir ist es umgekehrt (Ryzen 5 3600).
 
Danke, dann warte ich mal den Montag ab, da werden die ARP1 WUs in die Freiheit entlassen...

Bisher sieht mein Durchschnitt bei ARP so aus:
Code:
R9-3900x_Linux64 (24 threads)
            Project: #WUs: ~Runtime: ~Credits: C/d/Core: C/d/Host:
                ARP1  1844  64737.11    613.34    815.74  19577.76
                BETA     9   7030.08    116.40   1430.55  34333.20
                HST1     6  37646.33    425.24    973.79  23370.96
                MCM1    35   8715.98    114.06   1130.33  27127.92
                MIP1    73   5804.99     54.72    814.23  19541.52
                OPN1  6134   6859.90     80.98   1019.53  24468.72
                SCC1   479   3542.91     52.71   1285.06  30841.44

Und meinte nicht jemand, die SCCs würden mehr Credits abwerfen als die OPNs? Bei mir ist es umgekehrt (Ryzen 5 3600).
koschi postet ja immer mal ein paar Auswertungen, siehe oben.
Es könnte daran liegen, dass Du vielleicht Windows nutzt? SCC ist unter Linux gut doppelt so schnell, wenn ich das noch richtig in Erinnerung habe.
 
Ich dachte Grid und Obyte fliegen irgendwann raus? *noahnung*
 
In der letzten, credit abhängigen Runde. ;)
Bis dahin können sie uns fleissig ärgern. :D
 
Da mein Dual-Epyc nur Quad-Channel bestückung hat und die Laufzeiten mitunter hochschnellen; welches ist das passende Unterprojekt?
 
Danke, dann warte ich mal den Montag ab, da werden die ARP1 WUs in die Freiheit entlassen...

Bisher sieht mein Durchschnitt bei ARP so aus:
Code:
R9-3900x_Linux64 (24 threads)
            Project: #WUs: ~Runtime: ~Credits: C/d/Core: C/d/Host:
                ARP1  1844  64737.11    613.34    815.74  19577.76
                BETA     9   7030.08    116.40   1430.55  34333.20
                HST1     6  37646.33    425.24    973.79  23370.96
                MCM1    35   8715.98    114.06   1130.33  27127.92
                MIP1    73   5804.99     54.72    814.23  19541.52
                OPN1  6134   6859.90     80.98   1019.53  24468.72
                SCC1   479   3542.91     52.71   1285.06  30841.44

Und meinte nicht jemand, die SCCs würden mehr Credits abwerfen als die OPNs? Bei mir ist es umgekehrt (Ryzen 5 3600).
koschi postet ja immer mal ein paar Auswertungen, siehe oben.
Es könnte daran liegen, dass Du vielleicht Windows nutzt? SCC ist unter Linux gut doppelt so schnell, wenn ich das noch richtig in Erinnerung habe.

Zuletzt sieht das sogar noch vorteilhafter für SCC1 aus, obwohl sich ARP1 gebessert hat nachdem noch maximal 12 davon laufen dürfen:
Code:
R9-3900x_Linux64 (24 threads)
            Project: #WUs: ~Runtime: ~Credits: C/d/Core: C/d/Host:
                ARP1   490  50881.88    608.98   1029.17  24700.08
                HST1     6  31734.35    403.09   1096.40  26313.60
                SCC1  5972   3541.30     61.08   1489.74  35753.76
Aktuelle OPN1 Resultate habe ich nicht mehr...
 
Vier weitere Threads am Start.
 
Mein Samsung A10 werkelt auch mit 4 Kernen OPN mit. Nur wuprop will nicht
 
Hier Vergleich Win10 und Linux 20.04:
Code:
2400GE@3,2GHz Ubuntu 20.04 (8 threads)
            Project: #WUs: ~Runtime: ~Credits: C/d/Core: C/d/Host:
                HST1     2  67855.27    326.62    414.80   3318.40
                MCM1    86  10349.79     99.72    831.66   6653.28
                MIP1   225  10411.19     57.31    475.09   3800.72
                OPN1   361  12814.91     84.60    570.20   4561.60
                SCC1   173   4738.52     53.63    977.67   7821.36

2700@3,2GHz  Win10 (16 threads)
            Project: #WUs: ~Runtime: ~Credits: C/d/Core: C/d/Host:
                HST1     3  57543.79    385.39    578.08   9249.28
                MCM1   203   9048.14     87.96    839.13  13426.08
                MIP1    94   6175.99     50.72    709.06  11344.96
                OPN1   122   9912.00     84.46    735.64  11770.24
                SCC1   152  11197.88     66.00    508.86   8141.76
Und der Asus-PN50 4300U @2,7GHz mit Linux:
Code:
MINIPC-PN50 (4 threads)
            Project: #WUs: ~Runtime: ~Credits: C/d/Core: C/d/Host:
                ARP1   179  46013.46    603.99   1129.46   4517.84
                BETA    15   3681.17     66.91   1570.37   6281.48
                HST1     3  34458.10    431.68   1079.20   4316.80
                MCM1   273   5610.62     84.62   1302.30   5209.20
                MIP1   356   5625.55     52.37    803.87   3215.48
                OPN1  1559   5245.39     77.53   1276.91   5107.64
                SCC1   488   2329.73     55.60   2061.64   8246.56
 
Unter Linux führt kein Weg am SCC Bunker vorbei für die letzte Woche...
 
1603208216536.png

Das mit Gridcoin wird aber eng werden.
 
24 Thread hinzu für den Rest der Woche zumindest! :D
 
Das mit Gridcoin wird aber eng werden.
Schaumer doch erstmal, wie es mit Rechenzeit aussieht.
In der letzten Runde haben wir ca. 10 Jahre pro Tag verloren auf Gridcoin verloren, da sollten wird auf jeden Fall besser werden, sonst ist es nicht eng, sondern klar. Mehr als 7 Jahre pro Tag dürfen wir nicht verlieren.
 
Zurück
Oben Unten