Boinc unter Windows mit mehr als 64 Kernen oder Freds

Crashtest

Redaktion
☆☆☆☆☆☆
Mitglied seit
11.11.2008
Beiträge
9.274
Renomée
1.406
Standort
Leipzig
  • Docking@Home
  • BOINC Pentathlon 2011
  • BOINC Pentathlon 2012
  • BOINC Pentathlon 2013
  • BOINC Pentathlon 2014
  • BOINC Pentathlon 2015
  • BOINC Pentathlon 2016
  • BOINC Pentathlon 2017
  • BOINC Pentathlon 2018
  • BOINC Pentathlon 2019
  • BOINC Pentathlon 2020
  • THOR Challenge 2020
  • BOINC Pentathlon 2021
  • BOINC Pentathlon 2022
  • BOINC Pentathlon 2023
Bisher war es nicht möglich, sinnvoll Boinc unter Windows mit mehr als 64 Cores oder Threads laufen zulassen.

Bisher - denn nun geht es mit Boinc 7.16.16:

20.04.2021 11:24:27 | | Starting BOINC client version 7.16.16 for windows_x86_64
20.04.2021 11:24:27 | | log flags: file_xfer, sched_ops, task
20.04.2021 11:24:27 | | Libraries: libcurl/7.73.0-DEV OpenSSL/1.1.1h zlib/1.2.11
20.04.2021 11:24:27 | | Data directory: D:\BOINC.DATA
20.04.2021 11:24:27 | | Running under account Boss
20.04.2021 11:24:27 | | No usable GPUs found
20.04.2021 11:24:27 | | Windows processor group 0: 64 processors
20.04.2021 11:24:27 | | Windows processor group 1: 64 processors
20.04.2021 11:24:27 | | Host name: EPYC-WIN
20.04.2021 11:24:27 | | Processor: 128 AuthenticAMD AMD EPYC 7V12 64-Core Processor [Family 23 Model 49 Stepping 0]
20.04.2021 11:24:27 | | Processor features: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 htt pni ssse3 fma cx16 sse4_1 sse4_2 movebe popcnt aes f16c rdrandsyscall nx lm avx avx2 svm sse4a osvw ibs skinit wdt tce topx page1gb rdtscp fsgsbase bmi1 smep bmi2
20.04.2021 11:24:27 | | OS: Microsoft Windows 10: Professional x64 Edition, (10.00.19043.00)

Seit Boinc 7.16.16. tauchen die beiden Zeilen processor group 0 und 1 auf.
Boinc hat es endlich geschafft unter Windows die Aufteilung zu erkennen und auch zu nutzen:

Im Task-Manager sieht es dann so aus:
Unbenannt.png

Leider weißt Boinc die Hälfte der 128 Wuzen einer ganzen Gruppe zu sodass Kern-Springen statt findet - innerhalb der jeweiligen Processor Group. Hoffentlich wird das irgendwann auch noch gelöst.
Aber immerhin laufen jetzt 128 Wuzen innerhalb von 2 Processor Groups statt in einer.

Link:
Boinc 7.16.16 64Bit für Windows


Editsch:
Nach Deaktivierung vom Core Parking läufts rund - halt so rund wie es unter Windose laufen kann.
 
Zuletzt bearbeitet:
Ich will heute den Umstieg auch mal wagen und lasse gerade die Warteschlage leer rechnen. Wenn ich den alten BM runterschmeiße und den neuen drauf mache, muss ich dann alle Projekte und app_configs neu einrichten ooder gibt es beim Deinstallieren die Option, die lokalen Daten zu behalten?
 
Man kann ein Update machen ohne den alten zu deinstallieren
 
d.h. einfach install laufen lassen und drüber installieren (ohne deinstall alte Fassung)?
 
das macht der Installer ...
 
So, "Umrüstung" erfolgt.

Pro: 128 Threads werden auch benutzt:
1619695416805.png

Contra: Milkyay läuft schlechter/anders als vorher. Ich habe 2x Radeon VII mit jeweils 4 WU parallel. Mit altem BOINC liefen dort die Wuzen gleichmäßig mit 45 - 50 Sekunden. Mit neuem BOINC laufen einige wenige mit 30 Sekunden und viele über 90 Sekunden.
1619695549246.png

Ideen?
 
@eiernacken1983 Nachdem nun alle logischen Kerne der CPU genutzt werden, "verhungern" nun evtl. die GPUs, wenn der Steuer-Prozess für die GPU nicht mehr genügend Rechenzeit abkriegt. Im BOINC-Manager statt 100% CPU-Kerne vielleicht mal 98% oder 97% eintragen, damit der BM ein bißchen Ressourcen (2-3 logische Kerne) für den GPU-Steuerprozess freilässt, evtl. auch ein bißchen mehr, schließlich sind die VII schnelle GPUs.
 
Oha, zu früh gefreut:
1619697869022.png
Es laufen 128 Threads, aber mehrheitlich nur noch auf der oberen Hälfte der CPUs. Das hatte ich ganz am Anfang beim alten BOINC auch, dass es zunächst alle Threads in Anspruch nahm und nach kurzer Zeit nicht mehr!
Doppelposting wurde automatisch zusammengeführt:

Boinc neu gestartet:
1619698071487.png
Jetzt nutzt BOINC die untere Hälfte!
 
Kannst Du mal bitte die Meldungen als Screenshot reinposten, die der BOINC-Manager beim Start bringt? Das muss so aussehen wie bei Crashtest oben, der BM muss zwei Prozessorgruppen erkennen.
 
@eiernacken1983 Nachdem nun alle logischen Kerne der CPU genutzt werden, "verhungern" nun evtl. die GPUs, wenn der Steuer-Prozess für die GPU nicht mehr genügend Rechenzeit abkriegt. Im BOINC-Manager statt 100% CPU-Kerne vielleicht mal 98% oder 97% eintragen, damit der BM ein bißchen Ressourcen (2-3 logische Kerne) für den GPU-Steuerprozess freilässt, evtl. auch ein bißchen mehr, schließlich sind die VII schnelle GPUs.
Nee, das hat es leider nicht gebracht. Aber mit den Erkenntnissen weiter unten ist mir auch klar, warum nicht...
Doppelposting wurde automatisch zusammengeführt:

Kannst Du mal bitte die Meldungen als Screenshot reinposten, die der BOINC-Manager beim Start bringt? Das muss so aussehen wie bei Crashtest oben, der BM muss zwei Prozessorgruppen erkennen.
Voilá:
1619698452594.png

Sieht so aus, wie bei Crashtest!
 
Das Problem ist in dem Zusammenhang das man nicht wirklich beeinflussen kann welches CPU Projekt auf dem anderen Thread landet und dieser dann womöglich die mindest CPU Laufzeit wegfrißt. Deshalb schalte ich in einer solchen Kombi SMT immer ab.
Man verliert bei den GPU Projekten leider zu oft deutlich mehr als man bei den CPU Projekten gewinnen kann.
 
Das "neue" Hauptproblem ist ja überhaupt, dass bei mir nun doch nicht alle Threads genutzt werden, d.h. auch wenn ich CPU only rechnen würde, wäre das ja Mist, so wie es jetzt läuft!
 
Hm, der einzige Unterschied, den ich erkennen kann ist, dass Crashtest mit Windows 10 Version 21H1 unterwegs ist und Du noch mit 1909. Evtl. testweise mal mit einer jüngeren Windows-10-Version booten und schauen ob das Problem dann weg ist.
 
Gute Idee. Naheliegend, mal Win zu aktualisieren, aber da wäre ich gerade nicht draufgekommen *massa*
Doppelposting wurde automatisch zusammengeführt:

Windows-Updates habe ich durchgeprügelt (hat gedauert).

1619704704764.png
Ergebnis:1619704730120.png

Hat also nicht geklappt :-(
Es gibt immer kurze Phasen nach dem Neustart des Rechners, wo 100 % angezeigt wird. Dann fällt es irgendwann auf 75 % zurück!
Doppelposting wurde automatisch zusammengeführt:

Alle Win Updates gemacht; die Threadauslastung hat sich nicht geändert. Habe daher das Experiment abgebrochen und bin auf eine alte Version zurück.
 
Zuletzt bearbeitet:
Welche CPU Projekte rechnest noch nebenbei? Vielleicht benötigen die zuviel RAM und Boinc Pausiert die anderen Aufgaben. Steht vielleicht was unter den Meldungen im Boinc Manager, wenn er von 100% auf 75% runter geht?
 
Nee, RAM war nicht das Problem. Habe RAM-sparend ODLK gerechnet (weil die WUzen schön kurz sind). Da war trotz 128 Threads mehr als genug RAM frei. Es wurden auch 128 Threads als aktiv rechnend angezeigt. Wenn Threads mangels Ressourcen paussiert sind, steht das ja auch im Status.
 
@ceVoIX
Das Spiel kenne ich auch von den ersten Windows Versuchen mit meinem 3990X.
Es waren im BOINC zwar 128 Threads am laufen aber am Ende wurden nur 64 Kerne wirklich genutzt, was zu entsprechend langen WU Laufzeiten führte. Kam dann auch noch Last auf die restlichen virtuellen Kerne brachen die Laufzeiten noch weiter ein. So war Windows auf dem System praktisch nur ohne SMT sinnvoll einsetzbar.
Der Sheduler von Windows kam ganz einfach nicht mit der Config klar allerdings hatte ich meine Windows Versuche nur in der Anfangszeit gefahren und seither darauf nur noch Linux genutzt.
Gut möglich dass der Sheduler von Windows bei den späteren Versionen entsprechend nachgebessert wurde und die Veränderungen im neuen BOINC Manager erst damit greifen.
 
Nach meinen gescheiterten Win-Versuchen mit SMT hatte ich noch eine andere Idee: Da TN-Grid als Projekt, das unter Linux besser läuft, mal etwas Liebe von mir braucht, habe ich überlegt, dass ich SMT wieder einschalte und unter Win eine Linux-VM mit 123 Kernen einsetze. 4 Kerne brauch ich für MW und 1 Kern würde ich freilassen. Hätte das Aussicht auf Erfolg, dass BOINC in der Linux VM dann die Kerne auch voll nutzt ?
 
Kann ich mir ehrlich gesagt nicht vorstellen, weil der Windows-Scheduler ja immer noch drunter liegt und die Ressourcen für den Hyper-Visor bereitstellen muss - da liegt ja offenbar das Problem.
 
Ersteinmal brauchst Du dann auch eine VM, die mit so vielen Kernen umgehen kann.
Bei denen für den Privatgebrauch ist laaaange vorher schluss.
VM-Ware Player (den benutze ich regelmäßig) lässt nur max. 12 Kerne zu.
Bei Virtualbox sind es 32 (glaube ich).
 
Ersteinmal brauchst Du dann auch eine VM, die mit so vielen Kernen umgehen kann.
Bei denen für den Privatgebrauch ist laaaange vorher schluss.
VM-Ware Player (den benutze ich regelmäßig) lässt nur max. 12 Kerne zu.
Bei Virtualbox sind es 32 (glaube ich).
Okay, das ist dann eine sehr wichtige Info, die mich davor bewahren wird, vergeblich die VM aufzusetzen. Ich könnte dann natürlich 4 Maschinen gleichzeitig laufen lassen (werde ich natürlich nicht tun) :)

Muss ich die Kiste doch perspektivisch auf Linux umstellen. @koschi wird es kalt den Rücken runter laufen, wenn er die potentiellen Fragen auf sich zu rollen sieht*suspect*
 
Alles wird gut, komm auf unsere Seite, wir haben Kekse!
 
Zurück
Oben Unten