14. Pentathlon 2023: Hindernislauf/ehem. Marathon (Yoyo@Home; nur ECM und ECM P2!)

ja, waren nur ECM gleichzeitig.
Das muss das Projekt einfach besser hinbekommen.
Das manuell so finezutunen, dass es passt ist *admin* (zumal ich die Auslagerungsdatei aus habe)
 
Berechnungsfehler... :/
Wahrscheinlich wegen Speichermangels - damit bin ich beim Marathon raus. :(
Genau, nimm nur die ECM. Da ist ab und an mal eine mit 1GB Speicherbedarf dabei. Ansonsten so um 5MB
 
Zuletzt bearbeitet:
Nicht alle, die -ru- Varianten haben sich bei mir als echte Speicherfresser erwiesen die 3,6 GB und mehr unter Ubuntu belegten. Zwar nicht durchgehend aber das hilft einen auch nicht viel wenn alle gleichzeitig starten und in den gleichen Rechenschritten sitzen.
Für die ECM P2 sollte man besser 7,5 -10 GB pro WU einplanen.
 
Früher hatte yoyo 11GB pro ECM P2 Wuzen vorgegeben...

PS
mein kleiner v12 hatte irgendwie kein Netz - 23h Leerlauf *motz*

Aber nu ist der Römer am Start
 
Nicht alle, die -ru- Varianten haben sich bei mir als echte Speicherfresser erwiesen die 3,6 GB und mehr unter Ubuntu belegten. Zwar nicht durchgehend aber das hilft einen auch nicht viel wenn alle gleichzeitig starten und in den gleichen Rechenschritten sitzen.
Für die ECM P2 sollte man besser 7,5 -10 GB pro WU einplanen.
Ein System ist wahrscheinlich deswegen nun auch Offline. Nach dem Penta fliegen die ECM sofort wieder von den Systemen, habe keinen Lust auf zusatz Arbeit wegen schlechter WUs. Dafür gibts die Beta Test Funktion in Boinc
 
@TAL9000
Vermutlich denn als ich meinen Ripper füllte kamen bei den ECM WUs fast nur die -ru- Varianten rein.
Die verhalten sich von der Fortschrittsanzeige her ohnehin eigenartig, bis 20% zählen sie normal hoch und danach nur noch in 20er Schritten.
 
Die nähsten "ru" Varianten sind auf dem Celeron durch, die haben nur 8,5 h benötigt. *noahnung*
Scheinen also auch unterschiedlich zu sein.
 
Ru läuft echt nicht gut, aber ich habe fast keine anderen. Mal sehen, was neu reinkommt.
 
@Krümel
Scheint so zu sein, von den 64 bei mir aktuell laufenden -ru- WUs schnappen sich 8x 3,6 GB und mehr, eine 1,2 GB und der Rest dümpelt bei unter 1 MB rum.
Allerdings variiert deren Anzahl, wodurches warscheinlich nur um bestimmte WU Abschnitte geht.
Doppelposting wurde automatisch zusammengeführt:

Ohne Doppelbelegung des Kerns durch SMT hat sich bei mir die Berechnungszeit der -ru- WUs bei ca. 7:20h eingependelt.
 
Hallo zusammen,
habe Yoyo jetzt mit den folgenden app_config.xml Einstellungen am Laufen, um bei 5600X & 32GB noch Puffer beim RAM und für den CPU Overhead bei Prime (2 parallele Threads auf der 6900XT) zu haben:

<app_config>
<app>
<name>ecmP2</name>
<max_concurrent>1</max_concurrent>
</app>
<app>
<name>ecm</name>
<max_concurrent>4</max_concurrent>
</app>
</app_config>

Damit hätte ich jetzt erwartet, 4 ecm und 1 ecmP2 parallel zu bearbeiten.
Allerdings werden jetzt 12 WUs parallel bearbeitet..
Was mache ich falsch?*noahnung* *kopfkratz

Allen viel Spaß beim Pentathlon und gutes Gelingen!
Greetz
Doppelposting wurde automatisch zusammengeführt:

@TAL9000
Vermutlich denn als ich meinen Ripper füllte kamen bei den ECM WUs fast nur die -ru- Varianten rein.
Die verhalten sich von der Fortschrittsanzeige her ohnehin eigenartig, bis 20% zählen sie normal hoch und danach nur noch in 20er Schritten.
Das Verhalten habe ich hier bei den -as- und -cn- Varianten auch.
Das Projekt scheint noch nicht ganz ausgereift..
 
Zuletzt bearbeitet:
@Meisterfragger
vielleicht sind noch andere WU Typen dazwischen? Im Projekt nicht abgewählt. Nur eine Vermutung.
 
Wenn eine app_config.xml eingelesen wird, zeigt BOINC dies auch im event Log an. Da muss sie also auftauchen, wenn nicht, hat sich ggf noch eine Dateinamenserweiterung hineingeschlichen, aka app_config.xml.txt?
Findet BOINC die Datei, kann die event log Option unparsed_xml auch hilfreich sein.
 
Mein RAM ist voll ECM P2 sei Dank! Endlich mal Auslastung! ;D
 
@Meisterfragger
vielleicht sind noch andere WU Typen dazwischen? Im Projekt nicht abgewählt. Nur eine Vermutung.
WU Typen passen soweit.
Wenn eine app_config.xml eingelesen wird, zeigt BOINC dies auch im event Log an. Da muss sie also auftauchen, wenn nicht, hat sich ggf noch eine Dateinamenserweiterung hineingeschlichen, aka app_config.xml.txt?
Findet BOINC die Datei, kann die event log Option unparsed_xml auch hilfreich sein.
Der Tipp war hilfreich, danke. Config.xml wurde tatsächlich nicht eingelesen. Habe das nochmal angeschoben, und jetzt läuft's. *great*
Musste die Config aber auch gleich nochmal anpassen. Bei den Settings:

<name>ecmP2</name>
<max_concurrent>1</max_concurrent>
</app>
<app>
<name>ecm</name>
<max_concurrent>4</max_concurrent>

war die CPU nur zu 45% ausgelastet. Habe die Werte daher auf 2 und 8 verdoppelt, jetzt liegt die Auslastung bei 87%.
Damit sollten dann noch genügend CPU Ressourcen für den Overhead der GPU-Primelei verfügbar sein.

Greetz
 
Bei Yoyo bräuchte es eigentlich ein Script, um mal die eigenen WUs auszulesen.
Bei insgesamt 3000 WUs werde ich wahnsinnig, wenn ich die alle durchblättern soll.
 

Hilft Dir das weiter?
 
Schade, ausgerechnet yoyo klappt damit nicht.
"No support for Einstein@home (Drupal based) and Yoyo (ancient server code) yet."
 
Geht nicht, ich kann das aber ggf. einfach mal als CSV ausgeben lassen bei Yoyo, müsste ich später noch bissl basteln. Auswertung dann jeweils per Excel oder so...
 
Das würde ja reichen, wenn man einfach alle WUs in einer Excel-Tabelle hat. Dort kann man dann selbst filtern und rechnen.
 
Inkl. WU Typen? Das gibt nicht mal die Übersichtsseite der WU direkt her.

ecm und ecm P2 verwenden auch die gleiche Anwendung 705.01, könnte man höchstens noch am Namen festmachen. Der Name wird in der WU Übersicht (results.php) aber nicht angezeigt (alte BOINC Server Version).
Die Werte aus result.php wurde ich ungern alle abrufen wollen, das ist dann Faktor 20 höherer http Traffic für das Projekt
 
Der WU-Name könnte sicherlich helfen. Da hätte man vermutlich ECM und ECMP2
ecm_cn_1681994727_2_2266L_6682_P1_1

Ich wäre über jede Zusatzinfo dankbar. Aktuell sieht man ja nicht ma, wie viele WUs in welchem Status sind.
 
Alles hochgeladen aber werden nicht gemeldet. Bekomme: [error] No close tag in scheduler reply
Au Mist, das wird wieder mal an der alten Serversoftware liegen. :-(
Das kenne ich, wenn ich zuviele abgebrochene auf einmal zurückmelden will, weil zu viele WUs versendet wurden, die nicht bis zur Deadline berechnet wurden.
Bei mir half da bisher nur Projekt zurücksetzen. @yoyo Ich hoffe, es gibt eine bessere Lösung!?
Versucht mal in der cc_config

<max_file_xfers>20</max_file_xfers>
<max_file_xfers_per_project>20</max_file_xfers_per_project>

Das sollte das Problem umgehen.
Den ersten Wert auf 20 10 gesetzt hat geholfen. Danke. 800 WUs sind raus.
 
Zuletzt bearbeitet:
Am 03.11.2019 hatte MaxAMD400 seine app_config.xml vorgestellt.
Mit dieser Einstellung würde 1x ECM P2 und 7x ECM laufen.
Gleichzeitig würden auf einem System mit mehr als 8 Threads, maximal 8 Yoyo-WUs laufen.
Ich war mal so frei, und habe sie in unsere DC-Wiki mit aufgenommen.
 
Zuletzt bearbeitet:
Alles hochgeladen aber werden nicht gemeldet. Bekomme: [error] No close tag in scheduler reply
Au Mist, das wird wieder mal an der alten Serversoftware liegen. :-(
Das kenne ich, wenn ich zuviele abgebrochene auf einmal zurückmelden will, weil zu viele WUs versendet wurden, die nicht bis zur Deadline berechnet wurden.
Bei mir half da bisher nur Projekt zurücksetzen. @yoyo Ich hoffe, es gibt eine bessere Lösung!?
Versucht mal in der cc_config

<max_file_xfers>20</max_file_xfers>
<max_file_xfers_per_project>20</max_file_xfers_per_project>

Das sollte das Problem umgehen.
Den ersten Wert auf 20 gesetzt hat geholfen. Danke. 800 WUs sind raus.
gleiches Problem aufm Clusterrechner, auf 20 setzen hat nicht geholfen :-(
 
Alles hochgeladen aber werden nicht gemeldet. Bekomme: [error] No close tag in scheduler reply
Au Mist, das wird wieder mal an der alten Serversoftware liegen. :-(
Das kenne ich, wenn ich zuviele abgebrochene auf einmal zurückmelden will, weil zu viele WUs versendet wurden, die nicht bis zur Deadline berechnet wurden.
Bei mir half da bisher nur Projekt zurücksetzen. @yoyo Ich hoffe, es gibt eine bessere Lösung!?
Versucht mal in der cc_config

<max_file_xfers>20</max_file_xfers>
<max_file_xfers_per_project>20</max_file_xfers_per_project>

Das sollte das Problem umgehen.
Den ersten Wert auf 20 gesetzt hat geholfen. Danke. 800 WUs sind raus.
gleiches Problem aufm Clusterrechner, auf 20 setzen hat nicht geholfen :-(
Ich meinte natürlich 10 !!! Hatte ihn vorher auf 20, da ging es nicht.
 
Zurück
Oben Unten