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

[sompe]

Ich kau mal zum Wäschetrocknen auf "Jack" ein paar WUs durch, 256GB RAM sollten ja reichen.

 

[MagicEye04]

Yoyo macht aber auch komische Sachen bei mir, der genannte X6 hat sich beim Bunker von 3,5 Tage >1000WUs geholt

Ich habe auch einen Bunker von über 8000h auf einer Kiste. Das wären 16 Tage trotz nur 5 Tage Einstellung.
Das lag aber daran, dass ich dort einige andere WUs bekommen habe, die länger haltbar sind und 10x so lange laufen sollen. Ob es auch so sein wird, werde ich sehen.

 

[Viper00]

Mein Ryzen 7 3700X hätte auch 128GiB RAM für solche "dicken" WUs. Bis jetzt hat er noch keine abbekommen.

 

[JagDoc]

Das lag aber daran, dass ich dort einige andere WUs bekommen habe, die länger haltbar sind und 10x so lange laufen sollen. Ob es auch so sein wird, werde ich sehen.

Bei meinem 4700U:
ecm_cw_ haltbar bis 7.5. Laufzeit 1,5h
ecm_hc_ haltbar bis 7.5. Laufzeit 2h
ecm_cn_ haltbar bis 12.5. Laufzeit 11h

 

[MagicEye04]

Genau, _cn_ sind das bei mir auch.

 

[sompe]

Haben die normalen ecm WUs überhaupt Checkpoints?
Vorhin kackte offenbar der Boinc Client ab (BM ohne Verbindung, keine Last auf der CPU) und danach fingen die wieder bei 0 an.

 

[MagicEye04]

Ich hatte ja vorhin bei allen Rechnern die duration correction factor geändert und musste dazu auch den Client stoppen. Ich meine, dass die nicht alle bei Null los sind. Aber wenn ich aktuell schaue, dann liegt die Zeit seit dem letzten Checkoint zwischen 20 und 50 Minuten. Also vermutlich nur so alle 20%. Wenn die noch nicht viel weiter waren, dann fangen sie natürlich wieder bei Null an.

 

[olsen_gg]

Irgendwie habe ich den Verdacht, dass die Checkpoints auf den ECM nicht funktionieren. Auf der Ubuntumaschine habe ich 16 von den ganz langen laufen gehabt, gestern Abend ausgemacht, eben wieder an...
...und zack sind 13 von 16 wieder auf Null gesetzt und fangen neu an. Sch...eibenhonig.

Mal schauen, wie das auf den Windowsrechnern aussieht.

 

[sompe]

Na das passt ja denn bei mir ging es auch um Ubuntu. ^^
Dann ist ja gut das der über Nacht durch lief...

 

[olsen_gg]

Jo, auf dem 3700X alle 16 auf Null, auf dem 3900X 20 von 24 auf Null.
Damit werde ich wirklich ECM nur noch auf 24/7-PCs rechnen. Alles andere hat keinen Sinn.
Also erst einmal überall "no new work". Schade.

Doppelposting wurde automatisch zusammengeführt: 04.05.2023

Hat jemand Erfahrungen, ob sich der Effekt verhindern lässt, wenn man den PC nur in den Ruhezustand versetzt und nicht runterfährt?

 

[koschi]

Ruhezustand müsste funktionieren, hab ich aber nicht verifiziert.

 

[FritzB]

Eine Idee: in einer VM laufen lassen und die dann nicht runterfahren, sondern speichern.

 

[TAL9000]

wie war das bei win10:
Einstellungen -> Update & Sicherheit -> erweiterte Optionen -> Updates aussetzen -> Datum auf 20. Mai setzen

 

[enigmation]

Elche bitte!
Ich hatte in der client_state.xml die Scheduler-URL geändert, um die Fertigmeldung zu verhindern.
Ich weiß nicht warum, aber auf zwei Linux-Rechnern wurden die fertig gerechneten und hochgeladenen ecms auf einmal gemeldet. Und die client_state.xml hat auch nicht mehr die geänderte Scheduler-URL drin?!

Hier seht ihr, was passierte:

148 yoyo@home 04.05.2023 06:39:20 Started upload of ecm_ru_1683099621_10_1104.c217_8185_P1_0_0
149 yoyo@home 04.05.2023 06:39:20 Started upload of ecm_ru_1683099621_10_1104.c217_8185_P1_0_1
150 yoyo@home 04.05.2023 06:39:22 Finished upload of ecm_ru_1683099621_10_1104.c217_8185_P1_0_0
151 yoyo@home 04.05.2023 06:39:22 Finished upload of ecm_ru_1683099621_10_1104.c217_8185_P1_0_1
152 yoyo@home 04.05.2023 07:48:07 Sending scheduler request: To report completed tasks.
153 yoyo@home 04.05.2023 07:48:07 Reporting 8 completed tasks
154 yoyo@home 04.05.2023 07:48:07 Not requesting tasks: "no new tasks" requested via Manager
155 04.05.2023 07:48:09 Project communication failed: attempting access to reference site
156 yoyo@home 04.05.2023 07:48:09 Scheduler request failed: Couldn't resolve host name
157 04.05.2023 07:48:11 Internet access OK - project servers may be temporarily down.
158 yoyo@home 04.05.2023 10:13:35 Sending scheduler request: To report completed tasks.
159 yoyo@home 04.05.2023 10:13:35 Reporting 8 completed tasks
160 yoyo@home 04.05.2023 10:13:35 Not requesting tasks: "no new tasks" requested via Manager
161 04.05.2023 10:13:37 Project communication failed: attempting access to reference site
162 yoyo@home 04.05.2023 10:13:37 Scheduler request failed: Couldn't resolve host name
163 04.05.2023 10:13:39 Internet access OK - project servers may be temporarily down.
164 yoyo@home 04.05.2023 10:14:47 Fetching scheduler list
165 yoyo@home 04.05.2023 10:14:49 Master file download succeeded
166 yoyo@home 04.05.2023 10:14:54 Sending scheduler request: To report completed tasks.
167 yoyo@home 04.05.2023 10:14:54 Reporting 8 completed tasks
168 yoyo@home 04.05.2023 10:14:54 Not requesting tasks: "no new tasks" requested via Manager
169 yoyo@home 04.05.2023 10:14:55 Scheduler request completed
170 yoyo@home 04.05.2023 10:14:55 Project requested delay of 303 seconds

 

[seTTam]

Hat jemand ein entsprechendes update-Skript (Linux) zur Hand?
Habe wohl in meiner VM keins (mehr) drin. Ich nehme dafür auch gerne Elche entgegen

 

[TAL9000]

#!/bin/sh
#Zeit m
SLEEP=30s
PROJEKT=http://www.rechenkraft.net/yoyo/

while true
do
sleep $SLEEP
boinccmd --passwd passwort --project $PROJEKT update

done

Übertreibt es nicht, der Server zeigt schon Ausfall Erscheinungen...

 

[seTTam]

Lieben Dank, ich mache das nun nur ein paar Male, bis ich zufrieden bin

 

[sompe]

Ich glaube ich habe eine Ursache für den gestrigen Ansturz des Boinc clients gefunden denn heute trat wieder einer auf udn wiederholte sich nach einem Restart.
Einige normale ecm WUs scheinen ebenfalls zumindest zeitweise heftig RAM zu fressen denn auch nachdem alle P2 WUs pausiert wurden kletterte die RAM Auslastung lt. Systemüberwachung auf 263 von 270 GB. Das hielt dann ca. 10 Minuten an und fiel dann wieder auf ca. 75 GB runter. Würden dann noch die 10 P2 WUs mitlaufen....
Kann es sein das einige Varianten ein Speicherleck besitzen?

 

[Krümel]

Bei meinem 4700U:
ecm_cw_ haltbar bis 7.5. Laufzeit 1,5h
ecm_hc_ haltbar bis 7.5. Laufzeit 2h
ecm_cn_ haltbar bis 12.5. Laufzeit 11h

Weia, mein kleiner N5095 hat sich nur ecm_ru gezogen. Laufzeit: 20h 11min bis 20h 24min.

 

[Pegasushunter]

Bei meinem 4700U:
ecm_cw_ haltbar bis 7.5. Laufzeit 1,5h
ecm_hc_ haltbar bis 7.5. Laufzeit 2h
ecm_cn_ haltbar bis 12.5. Laufzeit 11h

Weia, mein kleiner N5095 hat sich nur ecm_ru gezogen. Laufzeit: 20h 11min bis 20h 24min.

Schau Dir mal den Namen hier der WU an. "

ecm_ru"

Dann weisst Du warum die so lange laufen muss.

 

[Maverick-F1]

Jo, auf dem 3700X alle 16 auf Null, auf dem 3900X 20 von 24 auf Null.
Damit werde ich wirklich ECM nur noch auf 24/7-PCs rechnen. Alles andere hat keinen Sinn.
Also erst einmal überall "no new work". Schade.

Doppelposting wurde automatisch zusammengeführt: 04.05.2023

Hat jemand Erfahrungen, ob sich der Effekt verhindern lässt, wenn man den PC nur in den Ruhezustand versetzt und nicht runterfährt?

Wie - Rechner "runterfahren"
Das mach' ich nur noch, wenn ich an der HW schraube - sonst ist das nicht notwendig - Ruhezustand und gut is!
Da macht die Maschine genau da weiter, wo sie sich zuvor schlafen gelegt hat - mach ich unter Windows seit > 10 Jahren nur noch so, funktioniert problemlos...

 

[sompe]

Kann es sein das die *ru* WUs bei den Speicherpunkten kräftig RAM fressen?
Seit ein Berg von denen läuft kommt mein RAM immer mal wieder an die Grenzen.

 

[TAL9000]

unter Win10 habe ich das nicht bemerkt, die Linux Systeme haben mehr RAM Bedarf, jedoch im erwarteten Rahmen

 

[sompe]

Jap, eben live erlebt.
Die Dinger fraßen teils fast 6 GB RAM und sobald die Swap Datei nicht mehr reicht um den RAM Überlauf aufzufangen schmiert der boinc client ab. Besonders ärgerlich da die um die 12h laufen.

Läuft bei mir mit Ubuntu 22.04

 

[Krümel]

Hmm, ich habe ja nur 8 GB bei 4 Threads und nur ne 120er SSD. Bis jetzt läuft es problemlos (Ubuntu 20.04).