Allgemeiner Plauderchat über das Thema DC Part III

Status
Für weitere Antworten geschlossen.
@denjo
Und bei deiner Statistik stehen max. 100% und avg. Werte zwischen 7% und 13,9% bei den 4 Threads.
Der Wert für die Gesammtauslastung der CPU ist dafür vollkommen irrelevant denn jeder Thread der CPU wird bei den Projekten als eine CPU angesehen. ;)

Edit:
Nur mal als Beispiel, mein 64 Kerner hat 128 Threads und damit werden singlethread WUs bereits bei 0,78125% angezeigter Gesammtauslastung limitiert.
 
Schlimmstenfalls heißt es dann eben am 15.4. Universe abliefern und entscheiden, ob man Sprint macht oder Universe weiter. Einen Mathe-Sprint mach ich eher nicht mit.
Race Start ist 2021-04-15 22:00 UTC, also erst ab 16.04.2021 00:00 unserer Zeit abliefern.

Meine 3 Kleinen mit Linux haben sich schon mit Universe eingedeckt.
 
@denjo
Und bei deiner Statistik stehen max. 100% und avg. Werte zwischen 7% und 13,9% bei den 4 Threads.
Der Wert für die Gesammtauslastung der CPU ist dafür vollkommen irrelevant denn jeder Thread der CPU wird bei den Projekten als eine CPU angesehen. ;)

Edit:
Nur mal als Beispiel, mein 64 Kerner hat 128 Threads und damit werden singlethread WUs bereits bei 0,78125% angezeigter Gesammtauslastung limitiert.
wir wissen alle das wir für ne einstein wu nen kern freilassen müssen. es geht doch darum das die freien kerne auf denen die einstein wus laufen nicht ausgelastet sind und aufgrund dessen die anderen kerne mehr boosten können was womöglich zu den verbesserten zeiten der tn-grid wus von eiernacken1983 geführt hat.

^^
 
Da ich aber nur 4 Threads entlastet habe, die Laufzeiten sich aber um 23 % reduziert haben, müsste der Takt ja um 29 % nach oben geschossen sein, um die Laufzeitreduktion zu erklären. Allcore läuft der bei 50 W auf 3,5 GHz, so dass man bei 4,5 GHz bei 12 Threads rauskommen müsste. Das wird es mit Sicherheit nicht sein, weshalb ich
a) auf den freien Cache
oder
b) auf weniger Rechenaufwand bei den WUs

getippt hätte. Aktuell läuft Einstein nicht mehr auf dem Rechner aber Hin und wieder (aber eben nicht lange) WCG und die Laufzeiten bei nunmehr meistens 16 Threads Auslastung liegen bei 9200 Sekunden


1618241869007.png

Scheint also eher b) gewesen zu sein. Kommt mir aber immer noch wie ein großer Zufall vor, dass dies ausgerechnet dann passiert, wenn ich CPU-Threads abziehe.
 
@eiernacken1983
Das Zauberwort könnte dafür "SMT" sein denn wenn sich die GPU WU den Kern mit einer CPU WU teilt kann es schnell mal vorkommen das die CPU WU zu viel Rechenzeit frißt und damit dem zweiten Thread mit der GPU WU das "Wasser" abgräbt. Dadurch verlängert sich natürlich die Laufzeit der GPU WU weil ihr die benötigte Rechenleistung von der CPU fehlt. Deshalb empfehle ich dringend bei einem solchen Mix Betrieb SMT abzuschalten denn diesen Effekt hatte ich schon mehrfach.
 
@sompe
Deine Schilderung passt nicht zu meiner Beobachtung. Durch den Mischbetrieb hat sich (mgwl.) die Laufzeit der CPU-WUs deutlich reduziert. Die Laufzeit der GPU-WU war vergleichbar mit Laufzeiten bei anderen Mitcrunchern (die die selbe GPU verwenden). Somit ist die GPU-WU nicht beeinträchtigt und die CPU-WU hat vom Mischbetrieb profitiert. Meine Erklärung wäre, dass der Takt leicht gestiegen ist (was aber nicht für die deutliche Verkürzung ausreicht) oder dass mehr L3-Cache freigeworden ist. Zudem hatten alle WUs vor und nach Mischbetrieb vergleichbare Laufzeiten mit den jeweils parallel ausgeführten WUs.
 
Bei SMT kann am Ende vieles rauskommen, je nachdem welcher Thread die höhere Priorität bekommt.
Laufen 2 WUs des gleichen Projekts auf dem gleichen Kern kann sich die Laufzeit ca. verdoppeln wenn die Rechenleistung des Kerns schon von einer WU gut ausgelastet wird, reicht für 2 WUs der Cache nicht mehr aus kann am Ende sogar deutlich weniger rauskommen.
Bekommt der Thread der GPU WU die höhere Priorität bremst dieser die CPU WU aus und bekommt der Thread der CPU WU die höhere Priorität bremst dieser eben die GPU WU aus wenn der Mindestbedarf an Rechenleistung unterschritten wird.

Was nur allso oft übersehen wird, SMT schafft keine zusätzliche Rechenkeinheiten sondern hilft nur die Ressourcen des Kerns besser zu nutzen.
 
@sompe
Deine Schilderung passt nicht zu meiner Beobachtung. Durch den Mischbetrieb hat sich (mgwl.) die Laufzeit der CPU-WUs deutlich reduziert. Die Laufzeit der GPU-WU war vergleichbar mit Laufzeiten bei anderen Mitcrunchern (die die selbe GPU verwenden). Somit ist die GPU-WU nicht beeinträchtigt und die CPU-WU hat vom Mischbetrieb profitiert. Meine Erklärung wäre, dass der Takt leicht gestiegen ist (was aber nicht für die deutliche Verkürzung ausreicht) oder dass mehr L3-Cache freigeworden ist. Zudem hatten alle WUs vor und nach Mischbetrieb vergleichbare Laufzeiten mit den jeweils parallel ausgeführten WUs.
Irgendwelche Einheiten sind halt nur 1x vorhanden und wenn die sich 2 WUs teilen müssen, dann schnellt die Zeit halt deutlich nach oben.
Das Taktbudget kommt halt noch oben drauf.
Doppelposting wurde automatisch zusammengeführt:

Hat Jemand eine Idee, wie ich bei Universe mehr als 1 WU pro Thread bekommen kann?
Es steht bereits auf 4+4 Tage und das Projekt wurde frisch hinzugefügt, also sind auch keine Altlasten da.

Mo 12 Apr 2021 19:05:18 CEST | Universe@Home | update requested by user
Mo 12 Apr 2021 19:05:22 CEST | Universe@Home | Sending scheduler request: Requested by user.
Mo 12 Apr 2021 19:05:22 CEST | Universe@Home | Reporting 1 completed tasks
Mo 12 Apr 2021 19:05:22 CEST | Universe@Home | Not requesting tasks: don't need (CPU: ; AMD/ATI GPU: )
Mo 12 Apr 2021 19:05:23 CEST | Universe@Home | Scheduler request completed

Von wegen don't need...
Andere Projekte bekommen ausreichend WUs, sind derzeit aber komplett leer gelaufen (no new WUs)
 
@MagicEye04
Das ist eben das grundsätzliche Problem mit SMT, zwischen einer Reduzierung der Rechenleistung aufgrund des höheren Verwaltungsaufwandes und einer Vervielfachung nach der Anzahl der Threads ist alles drin. Kommt es durch den zweiten Thread gar zum Cache Überlauf kann man sogar deutlich Leistung verlieren weil z.B. in den vergleichsweise langsamen RAM ausgelagert werden muss. Waren die ARP WUs bei der ersten Zen Generation nicht so ein Kandidat?
Was am Ende rauskommt hängt von der eingesetzten Software und natürlich auch vom kern Aufbau ab und das vollkommen unabhängig vom Takt.
 
Gut, dass Universe so genügsam beim RAM ist.
2048 virtuelle CPUs haben ohne Probleme in den Speicher gepasst. ;)
 
Nur ging es nicht um RAM sondern den Cache der CPU und dabei geht es eher darum was bei SMT auf dem anderen Thread landet.
Wie ich bereits schonmal schrieb, wenn die Einstein WU nicht ausgebremst wird dann dürfte bei SMT im Fall von Eiernacken1983 eben Universe Federn lasse, vollkommen egal wie sich der Takt entwickelt. Dann ist auch ganz schnell klar woher der Einbruch bei der Laufzeit kommt.
 
Nur ging es um ein ganz anderes Thema.
 
die sache mit tn-grid ist schon komisch
 
Zum direkt nach Fertigstellung hochladen, aber noch nicht melden:
Code:
#universe@home
127.0.0.1 debian1.universeathome.pl
::1 debian1.universeathome.pl
Dann hat es der Server am 16.4. ab 0Uhr nicht so schwer...
 
allcore oc lohnt sich gegenüber pbo. pbo fährt bei niedrigeren taktraten deutlich mehr vcore/vid.
dabei wird die Effizienz doch so gelobt *admin*
 
Heute der erste Tag Des BOINCWorkshop 2021


Start 18Uhr, dann folgender Ablauf:

START Matt Blumberg Welcome + the day’s agenda
+00:10 David Anderson BOINC Initiatives
+00:40 Marcus Belcastro Review of active BOINC projects
+00:55 Rytis Slatkevičius The Science Cloud
+01:10 Bruce Allen Einstein@home
+01:25 Ritu Arora BOINC@TACC: COVID Research
+01:40 David Wallom ClimatePrediction.net
+01:55 Juan Hindo World Community Grid: COVID Research
+02:10 John Clemens MachineLearning@home
+02:25 Nils Høimyr LHC@home
+02:40 Steven Clark nanoHUB
+02:55 Matt Blumberg Find.Bio + Charity Engine
+03:10 Matt Blumberg Wrap up + look forward to next week


Link zu Zoom wird nach Anmeldung zugeschickt...
 
Das war recht interessant, hoffe die Mitschnitte enden dann bald auf Youtube.
 
in 10 minuten den universe@home bunker leeren
 
2 vms waren voll ....brauch neue wus ... ^^
 
*knaaarrr* sagte die Bunkertür. ;)
Doppelposting wurde automatisch zusammengeführt:

Alles direkt in den anderen Keller zum Chinesen gewandert.
 
Zuletzt bearbeitet:
1500 wus sind ja relative ^^ wenn du die 30 minuten wus erwischt sind die ruckzuck weg ^^
sig.png

Überprüfung ausstehend (945) nur dreistellig ^^
 
Zuletzt bearbeitet:
Status
Für weitere Antworten geschlossen.
Zurück
Oben Unten