Primegrid: BOINC mehr CPU-Kerne vorgaukeln, als tatsächlich vorhanden

[Jürgen]

Hi,

aktuell rechne ich SGS,um noch den entsp. 25k WPprop-Stern zu erhaschen.
Dabei ist mir aufgefallen, daß SGS den Rechner nur zu ca. 85% auslastet.

Der Rechner hat 12 Kerne (mit HT 24), CPU ist ein Ryzen 9 3900x.
In PG habe ich 6 Threads und 100 Aufgaben eingestellt, es laufen also 4 Aufgaben a 6 Threads (=24).
Lt. Top (Linux) habe ich einen Load von 21 (bei Vollauslastung müßte das 24 sein), d.h. die Leistung von 3 Kernen wird nicht angefordert oder verpufft irgendwie durch interne Synchronisationsvorgänge.

Frage: kann man BOINC irgendwie vorgaukeln, daß die CPU mehr Kerne hat, um die besser auszulasten ?

[gemini8]

Man kann, indem man in den XML-Dateien herumpfuscht.
Die cc_config.xml und <ncpus> dürften das ermöglichen, was du möchtest.
Aber das wird dir eher nicht helfen. Zu den Tasks gehören nämlich die Uploads, die mit LLR2 größer geworden sind.
Und ich bekomme auf keinem meiner Rechner 100% Laufzeit bei auch nur einem Projekt hin.

[joe carnivore]

Der Upload wird wohl keine Rolle spielen. Außer du hast dein cache so klein das der Rechner erst danach sich eine WU zieht.

Wuprop hat auch öfter Schluckauf. Dann setzt der den Kontakt zum Server auf 3600 Sekunden.

Was Jürgen meint ist seine Anzeige bei htop.

Ich habe kein htop auf meine Linux Rechner. Die Systemüberwachung sagt mit das alle CPU Kerne auf 100% laufen ,mit Ausreisern auf 99%.

Mein 5700G (Windows10) zeigt nur 82% CPU Auslastung an. Bei 16x Sophie Germain und 1x Cullen/Woodall Sieve.
Die Grafik von der CPU läuft nicht mit. Muss ich mal ändern.

Mal sehen wie die CPU Auslastungen jetzt bei einen Projektwechsel aussieht.

PS.
Prime Grid belastet stark die CPU.
Der 5700G lief auf 3,08 GHz ,82% Auslastung . Core temp sagt 100%. Ich vermute der Task Manager geht auch auf die Untertaktung ein.

So Rakesearch drauf , 100 % bei 4,04 GHz.

[Kolossus]

So, wie ich das jetzt verstehe, redet ihr vom CPU-internen Cache. L1, L2 und L3.
Mit welchem Tool ist es überhaupt möglich, diesen Cache auszulesen, um überhaupt zu wissen, wieviel davon benutzt oder nicht ist
Mit den Tools wie HWinfo ist dies nicht möglich

[gemini8]

Wir sind nicht beim Cache, sondern bei der Auslastung der CPU allgemein.

[joe carnivore]

Zitat von mir.
Außer du hast dein cache so klein das der Rechner erst danach sich eine WU zieht.

Bedeutung : wir hoch der Pufferspeicher ist.

[Jürgen]

Wie schon eingange geschrieben, habe ich aktuell "100 Aufgaben" eingestellt, d.h es liegt immer schon eine neue Aufgabe bereit, wenn eine fertig geworden ist. Da kommt der Leerlauf also nicht her.

Ich habe jetzt aber die Threads von 6 auf 2 reduziert (und damit laufen jetzt 12 Aufgaben parallel), das scheint den Leerlauf schon deutlich reduziert zu haben.

[Yeti]

Also, mal etwas grundsätzliches zu dem Thema Mehrkern-WUs:

Nach meinem Wissen arbeiten nicht alle zugeteilten Cores gleichzeitig an einer Aufgabe, sondern ein Masterthread verteilt so viele Teil-Aufgaben, wie er Cores (Threads) zur Verfügung gestellt bekommen hat.

Jetzt nehmen wir das Beispiel ATLAS, weil da weiß ich es konkret: Die WUs haben intern 200 Aufgaben, bei einer Einstellung auf 6 Cores können alle 6 Cores 33 Durchgänge rechnen, dann sind 198 Aufgaben verarbeitet.

Der Masterthread kann jetzt nur noch 2 Aufgaben an 6 Cores / Threads verteilen, was machen die anderen 4 Cores/Threads ?

Deswegen bleiben häufig zwischendurch immer mal wieder Kerne unbeschäftigt.

[gemini8]

Bei PrimeGrid ist es nur eine Aufgabe, die auf mehrere Threads verteilt wird.
Je weniger Threads, desto besser skaliert die Applikation, was bedeutet, dass jeder zusätzliche Thread relativ gesehen weniger leistet, wobei insgesamt trotzdem mehr Leistung abgerufen wird.
Je nach System und Einstellungen kann es sein, dass bei der Anzahl der Cores die Grenze erreicht ist, hinter der die Rechenzeit wieder steigt, aber das muss nicht so sein. Meine Systeme laufen mit vollen Threads am effizientesten, aber das scheint eher ungwöhnlich.
Für die Rechenzeit sind natürlich volle Threads die beste Wahl.

Übrigens, Jürgen:
SGS läuft auf einem Thread ganz hervorragend, da alle Aufgaben in den L3-Cache passen.