Warum treten in regelmaessigen Abstaenden jedesmal die gleichen Kinderkrankheiten auf?

Die Datenbank kuerzt manchmal einige Eintraege von WUs. Die Ursache dafür ist das Alter der zugrundeliegenden Boinc-Server-SW. Ein Update dieser wuerde jedoch auch weitere Folgen fuer das darunter laufende Linux bedeuten und dazu ist der Admin noch nicht bereit. Als weiteres Handicap erweist sich, soweit ich das im Collatz-Forum herausgelesen habe, dass die aktuelle Server-SW neben einer sowieso noetigen Projektanpassung auch viel Nacharbeit bedeuten wuerde. Es wurde anscheinend mehr in EW-Zeit fuer ein neues Creditsystem investiert, als etwaige Bugs zu beheben. Ich kann nicht mal sagen, ob die Server-SW so ueberhaupt lauffaehig waere.

Werden immer und immer wieder die gleichen Arbeitspakete auf den Server geladen und berechnet?

Nein, wir sind mittlerererweile bei Pos 898 angelangt.

____________

Mit dem neuen Schwung WUs, der seit gestern Abend (02.02.11) läuft ist wieder jede Menge Schrott "unterwegs".
Laufzeiten >8h, Abbrüche durch Windows (Fehler wurde festgestellt, engine_r*.exe wurde beendet) und dadurch Blockade eines Kerns sind extremst ärgerlich und motivieren nicht besonders an diesem Projekt weiterzurechnen!

Warum treten in regelmässigen Abständen jedesmal die gleichen Kinderkrankheiten auf?
Werden immer und immer wieder die gleichen Arbeitspakete auf den Server geladen und berechnet?
____________

PS: In der Zeit als ich diesen Beitrag schrieb durfte ich 3 "aufgehängte" WUs per Taskmanager killen.

Mir gehts nicht anderes seit 3 jahren ist es quasie TOT es dürfte zwar jemand ein paar WU's reinstellen aber mehr nicht. Wenn ich mir die fehlerhafen WU's so ansehe ist jede Minute zu rechenen sinnlos. Ich schätze das so 500 - 700 WU's kaputt sind und immer wieder kommen man sieht es ja im Serverstatus.

____________
www.Woodworm.at

Wenn man den Programmcode schon nicht repariert, waere es eventuell auch eine ganz gute Idee, wenigstens die generierten WUs einer rudimentaeren Kontrolle zu unterziehen.

Die sind naemlich nur knappe 80 Bytes gross und koennten leicht daran erkannt und mit einem simplen Shell-"find"-Konstrukt geloescht werden. Gut, das gaebe dann Downloadfehler, aber dass das Programm nach dem Abbruch im Speicher bleibt und weiterhin volle Kanne die CPU belastet, finde ich das schlimmere Uebel.


p.s.: 4,5 Jahre Alphastatus halte ich fuer keine wirklich gute Ausrede
____________

Nö, ich habe auch diese Probleme.

Bitte bedenken, dass dieses Projekt den alpha-Status hat.

Es gibt allerdings auch keinerlei Bestrebungen aus dem Alphastatdium herauszukommen.

Ärgerlich wäre allerdings, wenn die "Programmmacke" schon seit langem besteht. Wie ich vermute.

Es ist ja nun nicht das erste Mal, dass ein Batch quasi mit Volldampf gegen die Wand gefahren wird.

Die, die dieses Projekt beaufsichtigen, haben einen Vorteil ;-)

Dazu sage ich besser nichts ^^
____________

Nö, ich habe auch diese Probleme.

Bitte bedenken, dass dieses Projekt den alpha-Status hat.

Ärgerlich wäre allerdings, wenn die "Programmmacke" schon seit langem besteht. Wie ich vermute.

Die, die dieses Projekt beaufsichtigen, haben einen Vorteil ;-)
____________


"Rasen sie ruhig, wir schneiden sie raus - ihre Feuerwehr"

Habe nur ich diese Probleme?

Falls Nein, ein Vorschlag von mir:
Da die Ausfallquote inzwischen weit über 50% liegt (zum Glück habe ich das Projekt nicht über Nacht unbeaufsichtigt laufen lassen) würde ich vorschlagen den Batch komplett einzustampfen.

Egal wie man zum Projekt steht, solange die Apps einen solchen Müll produzieren ist jede Sekunde Rechenzeit pure Verschwendung und ihr tut euch, den Usern und dem Projekt damit keinen Gefallen.
____________

Einerseits ist es schön zu sehen, dass mal wieder kräftig Arbeit "nachgelegt wurde", andererseits tauch(t)en wieder vermehrt WUs auf, die sich in Endlos-Loops verfangen.
Nach >20min (die CPU time-Anzeigen stimmt in dem Fall auch nicht) ein Fortschritt von ~5% ??? *klicks*
Gut dass ich die Dinger so früh entdeckt (und manuell abgebrochen) hatte.
____________

Hab ich grad probiert und bekomme bei deinem Link die Mitteilung, daß ich dazu angemeldet sein muß. Wenn die Anmelde-Email endlich mal durch die Graywall durch ist, werd ich mein Glück probieren. Mehr als nein sagen kann er ja nicht...
____________

Würde ich gerne machen, bin mom irgendwie nicht bei YoYo im Forum angemeldet oder ich bin zu plöt. Sollten meine yoyo@home-Daten nicht reichen oder ist das wie auch bei Spinhenge?

Schick ihm doch einfach 'ne "private Message" mit 'ner höflichen Anfrage. Dazu musst Du nicht unbedingt im Forum angemeldet sein.
____________

Falls jemand ein Schachbrett da hat, müßte man die aktuelle Position mal nachstellen.

Äh, wie würde man denn sowas machen? Das wär ja wirklich mal interessant.

Würde ich gerne machen, bin mom irgendwie nicht bei YoYo im Forum angemeldet oder ich bin zu plöt. Sollten meine yoyo@home-Daten nicht reichen oder ist das wie auch bei Spinhenge?
____________

Warum sprichst Du zum Thema Wrapper mal nicht mit Yoyo von den Rechenkraft'lern. Falls er hier nicht mehr aktiv sein sollte (ich sehe Du rechnest selbst Yoyo@home), kannst Du es ja mal bei seinem Projekt per "private Message" versuchen
Ich glaube mich düster erinnern zu können, dass er bei Yoyo@home auch die Wrapper im Einsatz hat.
Fragen kostet ja nix.
____________

Hmm, daß hatte ich fast befürchtet. Dann scheint Chess960 das gleiche Problem wie uFluids zu haben, dort läßt sich manchmal die App auch nicht durch Boinc beim Beenden schliessen und basiert ebenfalls auf der Wrapper-Technik. Jedenfalls werd ich das so auch dem Admin weiterleiten.

[edit]
Falls jemand ein Schachbrett da hat, müßte man die aktuelle Position mal nachstellen. Ich vermute ja ganz stark, daß entweder Schach angesagt oder Patt/Remis oder sogar in der Endposition Matt ist. Da ja dann an dieser Stelle alles gelaufen ist, erkennt die App das vielleicht nicht 100%ig und hängt dann in einer Endloss-Schleife. ABER wissen tu ich das auch nicht, ich vermute es nur.
____________

Mir sind gerade auch 38... er stehen geblieben. Insgesamt laufen alle stark verlangsamt und benötigen statt 4-6 Minuten eher 6-20 Minuten.
____________
Dragons can fly because they do not fit into pirate ships!

Ich habe mir jetzt mal den Spaß gemacht und eine der fehlerhaften WUs mehrfach laufen lassen (wie im englischsprachigen Thread gewünscht).
Dabei handelt es sich um folgendes Teil.
Testweise habe ich, als sich die WU als Endlosschleife entpuppte BOINC komplett beendet. Die "Engine" lies sich davon nicht sonderlich beeindrucken und lief fröhlich weiter. Nach einem manuellen "Shut Down" per Taskmanager und Neustart des BOINC-Managers startete die WU neu und hängte sich an der gleichen Stelle wie schon im ersten Versuch auf.
Hier die dazugehörige stderr_out:

<core_client_version>5.10.20</core_client_version>
<![CDATA[
<stderr_txt>
Chess960athome Wrapper (build 33; 200608301916) starting

Setting up default values
Processing command line arguments (11)
Command line:
projects/www.chess960athome.org_alpha/chess960_1.26_windows_intelx86.exe -nodes 150000000 -engineid 0 -ps 70 -debug 2 -startup "fen rkbrnbqn/pppppppp/8/8/8/8/PPPPPPPP/RKBRNBQN w ACac - 0 1 - 0 1 moves d2d4 d7d5"

Resolved input file name: ../../projects/www.chess960athome.org_alpha/41691_2
Startup position: fen rkbrnbqn/pppppppp/8/8/8/8/PPPPPPPP/RKBRNBQN w ACac - 0 1 - 0 1 moves d2d4 d7d5
1:-nodes 150000000
150000000
2:[skip]
3:-engineid 0
glaurung_1.2.1_windows_intelx86.exe
4:[skip]
5:-ps 70
70
[unrecognized]
6:[skip]
7:-debug 2
2
[unrecognized]
8:[skip]
9:Finished processing command line
Preparing input file
Using slot ID 5 for engine name
Preparing launcher
launch.bat: engine_r5.exe < input > ../../projects/www.chess960athome.org_alpha/chess960_41691_2_7_0
Copying Glaurung dependencies
Retval for kpk.bin: 0
Retval for engine_r5.exe: 0
Ready to launch launcher
Process created
Sleeping to let chess engine start
Found process: engine_r5.exe (ID: 448)
Got request to kill app
Chess960athome Wrapper (build 33; 200608301916) starting

Setting up default values
Processing command line arguments (11)
Command line:
projects/www.chess960athome.org_alpha/chess960_1.26_windows_intelx86.exe -nodes 150000000 -engineid 0 -ps 70 -debug 2 -startup "fen rkbrnbqn/pppppppp/8/8/8/8/PPPPPPPP/RKBRNBQN w ACac - 0 1 - 0 1 moves d2d4 d7d5"

Resolved input file name: ../../projects/www.chess960athome.org_alpha/41691_2
Startup position: fen rkbrnbqn/pppppppp/8/8/8/8/PPPPPPPP/RKBRNBQN w ACac - 0 1 - 0 1 moves d2d4 d7d5
1:-nodes 150000000
150000000
2:[skip]
3:-engineid 0
glaurung_1.2.1_windows_intelx86.exe
4:[skip]
5:-ps 70
70
[unrecognized]
6:[skip]
7:-debug 2
2
[unrecognized]
8:[skip]
9:Finished processing command line
Preparing input file
Using slot ID 5 for engine name
Preparing launcher
launch.bat: engine_r5.exe < input > ../../projects/www.chess960athome.org_alpha/chess960_41691_2_7_0
Copying Glaurung dependencies
Retval for kpk.bin: 32
Retval for engine_r5.exe: 32
Ready to launch launcher
Process created
Sleeping to let chess engine start
Found process: engine_r5.exe (ID: 448)
Got request to kill app
Chess960athome Wrapper (build 33; 200608301916) starting

Setting up default values
Processing command line arguments (11)
Command line:
projects/www.chess960athome.org_alpha/chess960_1.26_windows_intelx86.exe -nodes 150000000 -engineid 0 -ps 70 -debug 2 -startup "fen rkbrnbqn/pppppppp/8/8/8/8/PPPPPPPP/RKBRNBQN w ACac - 0 1 - 0 1 moves d2d4 d7d5"

Resolved input file name: ../../projects/www.chess960athome.org_alpha/41691_2
Startup position: fen rkbrnbqn/pppppppp/8/8/8/8/PPPPPPPP/RKBRNBQN w ACac - 0 1 - 0 1 moves d2d4 d7d5
1:-nodes 150000000
150000000
2:[skip]
3:-engineid 0
glaurung_1.2.1_windows_intelx86.exe
4:[skip]
5:-ps 70
70
[unrecognized]
6:[skip]
7:-debug 2
2
[unrecognized]
8:[skip]
9:Finished processing command line
Preparing input file
Using slot ID 5 for engine name
Preparing launcher
launch.bat: engine_r5.exe < input > ../../projects/www.chess960athome.org_alpha/chess960_41691_2_7_0
Copying Glaurung dependencies
Retval for kpk.bin: 32
Retval for engine_r5.exe: 0
Ready to launch launcher
Process created
Sleeping to let chess engine start
Found process: engine_r5.exe (ID: 1900)
Application exited. Processing output files
All done.

</stderr_txt>
]]>

Vielleicht kann ja irgendjemand etwas damit anfangen?

Achja, mir ist aufgefallen, dass nur WU der 41000-er Reihe betroffen sind. Könnte man die Teile vielleicht einfach vom Server nehmen? *und möglichst gleich in die Mülltonne*
____________

Bei mir sieht es da leider nicht anders aus...
____________

Hast du Erfahrung in der App-Entwicklung? Wenn ja, würde ich mich beim Admin erkundigen und deine Bewerbung umgehend weiterleiten.

Leider nicht, ansonsten hätte ich mich mit Sicherheit schon entsprechend selber gemeldet.
____________

Hast du Erfahrung in der App-Entwicklung? Wenn ja, würde ich mich beim Admin erkundigen und deine Bewerbung umgehend weiterleiten.

____________

Wie der Titel schon aussagt, ist es seit einigen Tagen nicht mehr möglich Chess ohne Aufsicht laufen zu lassen.
Mir ist noch nicht ganz klar woran es genau liegt, allerdings habe ich die neue Generation WUs im Verdacht. Immerhin hat sich ja an der App seit Jahren nichts geändert ^^
Ich finde es bedenklich, wenn von 4 gleichzeitig startenden WUs, sich eine als Langläufer entpuppt, die von Hand "gekillt" werden muss. Was dadurch in den vergangenen Tagen bereits an Rechenzeit vergeudet wurde, möchte ich nicht wissen.
Auch wenn ich gern die 100k noch erreichen würde, lautet mein Vorschlag momentan: Schaltet das Projekt solange ab, bis sich jemand gefunden hat, der fähig ist, die seit Jahren bekannten und die neurdings auftretenden Bugs aus der App zu entfernen bzw. eine komplett neue funktionierende App zu schreiben! Nur auf Krawall das fehlerhafte Projekt weiterlaufen zu lassen sorgt irgendwann dafür, dass sich niemand mehr daran beteiligen will.

PS: In der Zeit als ich diesen Beitrag schrieb durfte ich 3 "aufgehängte" WUs per Taskmanager killen.
____________