Wosn dös??? 5w 0d 13h 13m 54s (3071634.3803777 s)

[Norman]

meine 2 intros und 2 weitere langlauf-WU sind auch futsch. (systemfreeze)
keine checkpoints = keine langläufer mehr.
das geht mir mittlerweile auf den keks.
sorrrrry .

[Ananas]

Wenn der Heartbeat-Timeout hochgesetzt ist, werde ich es wieder probieren - hoffentlich sind dann mal Felis 'dran, dir kacken wenigstens nicht ueberall auf den Gehweg

[Ananas]

Ich hab' noch einen "Killer" ausgemacht :

openMalariaB schreibt bei mir etwa alle 3 Minuten einen komprimierten Checkpoint von 16MB und mehr (unkomprimierte Groesse).

Das geht eine ganze Weile ziemlich gut, bis sich ein paar Malaria-WUs mit ihren Checkpoints zufaellig synchronisiert haben. Ab da ist es nur noch eine Frage der Zeit, bis die erste Heartbeat-Meldung kommt. Es geht natuerlich schneller, je mehr Malarias gleichzeitig laufen.

Da ab jetzt _alle_ Malaria-WUs exakt synchron laufen (sie werden ja sofort nach dem Heartbeat-Fehler synchron nachgestartet), tritt ab diesem Zeitpunkt der Fehler zuverlaessig(!) alle 3 Minuten auf und das System wird erst wieder stabil, wenn alle Malaria-WUs verbraucht sind.

Meine HDD im betroffenen System ist nicht sonderlich schnell (aber nahezu lautlos), ich gehe daher davon aus, dass hier nicht die CPU-Leistung sondern der HDD-Zugriff den Engpass darstellt. Der Coreclient braucht in der Situation einfach zu lang, um die (bei diesem System mit 650k recht grosse) client_state.xml zu schreiben. Der HDD-Cache hilft bei der Datenmenge aus mehreren Threads nicht.

Ob dabei auch eine Rolle spielt, dass die Projekt-Task sich waehrend des Checkpointings im "critical"-Modus befindet (nicht ansprechbar durch den Coreclient) weiss ich nicht - ich glaube es aber nicht, da das gesamte System zu dem Zeitpunkt nicht mehr bedienbar ist und nicht nur der Coreclient.

Im Malaria-Forum haben sich schon andere ueber haeufige Heartbeatfehler beklagt, ob da noch jemand nachforscht, weiss ich aber nicht.

Das nur mal so als Beispiel, um die Idiotie klarzumachen, die in dem Heartbeat-Mechanismus steckt. In 99% aller Faelle verursacht dieser "Sicherheitsmechanismus" einen Schaden, die Situation, dass der Coreclient sich beendet und "lebende" Projektclients hinterlaesst ist nach meiner Erfahrung extrem selten und das ist die einzige Situation, die damit abgefangen werden soll.


p.s.: Die Analyse war ziemlich schwierig, da weder Coreclient noch Projektclients eine Meldung ausgeben, wenn ein Checkpoint geschrieben wird. Zudem kann das Slotverzeichnis nicht gut ueberwacht werden, da das gesamte System fast nicht mehr reagiert.

[Michael H.W. Weber]

Faszinierend. Ich frage mich wirklich, wie lange das BOINC Entwicklerteam eigentlich noch warten will, um diesen Unsinn zu beheben? Beispiele für das Problem gibt es ja nun wohl wie Sand am Meer...

MIchael.

[Matthias Lehmkuhl]

ich hab wohl auch einen erwischt.
http://www.rnaworld.de/rnaworld/result. ... d=13183458
cms_GA-p[e30-50MB_Lin64s]_1_Danio-rerio-(zebrafish)_CU651622.lin.EMBL_RF00028_Intron_gpI_1315448223_30212
werde es mal testen, aber 5w 5d 5h 40m 22s (3476422.304718 s) ist schon verdammt viel Zeit.
Mein Rechner hat zwar nur 8GB, vielleicht reicht es ja.

[Matthias Lehmkuhl]

ich hab wohl auch einen erwischt.
http://www.rnaworld.de/rnaworld/result. ... d=13183458
cms_GA-p[e30-50MB_Lin64s]_1_Danio-rerio-(zebrafish)_CU651622.lin.EMBL_RF00028_Intron_gpI_1315448223_30212
werde es mal testen, aber 5w 5d 5h 40m 22s (3476422.304718 s) ist schon verdammt viel Zeit.
Mein Rechner hat zwar nur 8GB, vielleicht reicht es ja.

Puh, geschafft
heute hat Sie Ihr Ende erreicht nach nur einer CPU time von 2492586 s
Jetzt muss sich nur noch ein Wingman finden, der auch bis zum Ende durchhält.
Bisher haben schon 3 abgebrochen.