milkyway@home: seltsame n-body work units in beta-phase?

[Simon Jäkle]

Ich erhalte auf meinem AMD octcore seit mehreren Wochen n-body problem tasks / work units, die werden in 3 Stunden zu etwa 30% erfüllt, doch dann steigt die angegebene Rechendauer von etwa 2h40min immer weiter an, bis auf sechs Tage (nach etwa 50 Stunden Rechnerei), oder vielleicht noch mehr. Ich hatte schon früher auf einem quad core n-body problem work units, die waren mit 23minuten Rechenzeit angegeben, brauchen dann jedoch 23 Stunden. Die Rechnerei läuft über alle jeweils verfügbaren Kerne, das wird dann so etwas wie multithreading sein, doch wenn das work amount immer weiter steigt oder angehäuft wird, aber mit den Stunden kein progress angezeigt wird, liegt mir die Vermutung nahe, dass sich der Rechenvorgang irgendwie «aufhängt», wie in einer Endlosschlaufe, oder "Nebenarbeit anhäuft". Oder dass das wie in holprigen asteroids@home parallel work units länger dauert, bis sich dann ein progress von mehreren Prozent ergibt. Ich muss wohl erst eine 6-tages work unit durchlaufen lassen, um zu sehen, ob diese am Schluss einen Riesenschritt in den erfüllten Prozenten macht. Ich finde den Umfang der work units massig, wenn ich nur einen Kern dafür am laufen hätte, hätte dieser anderthalb Monate, doch die work units werden doch schon nach ein paar Tagen wieder abgezogen. Das boinc System hätte mich gerne als Mainframe (oder dass ich einen alten pc als boinc server hätte einrichten können), weil die nicht parallelisierbaren n-body problem Rechnereien nur von Wenigen ausgerechnet werden? Hat das Team von milkyway@home viel zu wenig seriell ausführende Kerne in deren Mainframes, weil das Rechnen unergiebig oder ineffizient ist? Ich konnte bisher nirgends lesen, ob n-body sich hier auf Orreries (der mehreren tausend confirm-eten Exoplaneten), oder jeweils auf zwei sich umkreisende Sterne bezieht, das Team um milkyway@home sollte erklären, für was man das errechnet. Aber wer hatte bisher work Units, die mit mehreren Kernen in "multi-threading" kalkulierten?

[Simon Jäkle]

Da ich das "Aufhäuf"Problem auch bei asteroids@home und einstein@home bekomme, wird das ein "bug" auf der cpu (oder dann auf dem socket dazu, was ich weniger wahrscheinlich fände) sein, ich suche mir nun einen Treiber für die AMD Ryzen 5 2400G (mit Radeon RX vega 11 gpu, also integrated graphics card) cpu, vielleicht bringt das 'was (und hoffentlich keine Verschlimm-besserung, wie dies in technischen Produkten je länger desto "unvermeidlicher" zu werden scheint). Zudem habe ich etwas ähnliches auf meinem 5 Jahre älteren desktop pc (die hätten low profile Grafikkarten), jedoch nur bei einstein@home, dass die Fortschritts-prozente stehenbleiben (bei angegegebenem weiterrechnen), oder dass die Fortschritt-prozente beim einschalten des desktop pc's wieder bei 0 beginnen (immer aktuelle Zeitrechnung?), noch in 2022 hatte ich das so nicht, meinte ich, da hat jemand vielleicht den "boinc code" verschlimm-bessert. Ich hoffe Anderes.

[sarchery]

Es ist möglich, dass Arbeitseinheiten scheinbar nur langsam Fortschritte machen oder eine Zeit lang bei bestimmten Prozentsätzen stecken bleiben, bevor sie plötzlich Fortschritte machen. Dieses Verhalten kann aufgrund der Art der beteiligten Berechnungen oder der Art und Weise auftreten, wie der Projektfortschritt gemeldet wird. Bei manchen Aufgaben ist möglicherweise ein erheblicher Rechenaufwand erforderlich, bevor ein spürbarer Fortschritt angezeigt wird.

*edit*
Versteckten SPAM entfernt.
*end edit*