Tomáš Brada Experimental Grid

[Michael H.W. Weber]

..."Get Symmetrical Tupels" - send work: disabled.

Michael.

[Nataly-Mak]

..."Get Symmetrical Tupels" - send work: disabled.

Die Ausgabe von Aufgaben wird ausgesetzt, damit ich die Ergebnisse herunterladen kann.

das ist also OK

Es gibt bereits Ergebnisse

Code: Alles auswählen

11 32688925276700987273653: [18,30,12,18,6,6,18,12,30,18]
11 32688925286963770432891: [48,42,42,30,48,48,30,42,42,48]

[joe carnivore]

...die weiterlaufenden Tasks schreiben übrigens anhängend in das Ergebnislog. Eine "bit-wise results comparison" (für Mathematikprojekte zwar oft nicht erforderlich) ist nicht möglich, bzw. würde falsche Resultate liefern.

Wird ein Taskabbruch erzwungen (durch Beenden im Taskmanager möglich), meldet der BOINC-Manager nicht etwa einen Fehler, sondern ein "successful result". Was mit diesen Tasks auf dem Server passiert, kann ich (noch) nicht sagen: Hochgeladene "Ergebnisse" erscheinen dort offenbar erst mit einer gewissen Verzögerung.

Michael.

Michael deine Aussage zum pausieren kann ich bestätigen. Da ich auf einen Quadcore nur 3 zugelassen habe lief der so durch. ohne Fehler. Der klaute meiner GPU CPU Zeit.
Aber das war die letzte Meldung von mir dazu. Ende.

[Nataly-Mak]

Belassen Sie die fehlerhafte Anwendung in Gerasim@Home und starten Sie eine neue Anwendung (z. B. auf der yoyo@home-Plattform), die fehlerfrei funktioniert.

[Nataly-Mak]

..."Get Symmetrical Tupels" - send work: disabled.

Ich habe die Ergebnisse heruntergeladen.

Get Symmetrical Tuples
Send work: Enabled

[Stiwi]

Belassen Sie die fehlerhafte Anwendung in Gerasim@Home und starten Sie eine neue Anwendung (z. B. auf der yoyo@home-Plattform), die fehlerfrei funktioniert.

Wieso sollte man das tun? Sorry aber wenn man so mit Fehlerreports umgeht dann muss man sich nicht wundern wenn wenige die Projekte rechnen möchte. Also viel erfolg mit deinem Projekt aber so vergrault man nur Unterstützer.

Ich mein es ist ja ok wenn man gerade keine Möglichkeit hat das Problem zu fixen, dann schreibt man einen Hinweis auf die Seite und jeder weiß worauf er sich einlässt aber den Fehler abzustreiten und danach zu sagen dann mach doch eine bessere Anwendung nur weil man freundlich auf das Problem hinweist ist nicht gerade die feine Art

[Nataly-Mak]

Ich bin nicht hierher gekommen, um über die Arbeit des Gerasim@Home BOINC-Projekts zu sprechen.

Ich kam hierher, um Hilfe beim Start eines neuen BOINC-Projekts zu erhalten.

[Stiwi]

Ich dachte es ist deine Anwendung was jetzt bei Gerasim@Home läuft? Naja wie auch immer ich halte mich jetzt hier raus, für mich ist das Thema erledigt^^

[Michael H.W. Weber]

...die weiterlaufenden Tasks schreiben übrigens anhängend in das Ergebnislog. Eine "bit-wise results comparison" (für Mathematikprojekte zwar oft nicht erforderlich) ist nicht möglich, bzw. würde falsche Resultate liefern.

Wird ein Taskabbruch erzwungen (durch Beenden im Taskmanager möglich), meldet der BOINC-Manager nicht etwa einen Fehler, sondern ein "successful result". Was mit diesen Tasks auf dem Server passiert, kann ich (noch) nicht sagen: Hochgeladene "Ergebnisse" erscheinen dort offenbar erst mit einer gewissen Verzögerung.

Michael.

Michael deine Aussage zum pausieren kann ich bestätigen. Da ich auf einen Quadcore nur 3 zugelassen habe lief der so durch. ohne Fehler. Der klaute meiner GPU CPU Zeit.
Aber das war die letzte Meldung von mir dazu. Ende.

Danke für's Testen und reproduzieren.

Michael.

[Nataly-Mak]

Ich dachte es ist deine Anwendung was jetzt bei Gerasim@Home läuft?

Ja, meine Anwendung funktioniert in Gerasim@Home.
Mein Projekt ist so groß, dass es in mehreren BOINC-Projekten ausgeführt werden kann, einschließlich yoyo@home.

Leider weiß ich nicht, wie man ein BOINC-Projekt durchführt.
Deshalb bitte ich um Hilfe.

Zwei meiner Kollegen starten hier gerade ein neues BOINC-Projekt
https://boinc.termit.me/adsl/

Ich hoffe wirklich, dass es ihnen gelingt.

[Michael H.W. Weber]

Es sind wohl noch mehr Dinge kaputt: Bekomme bei manchen Maschinen keine WUs.
Der BOINC-Manager meldet, es sei kein (Sub-) Projekt gewählt worden. Das ist aber falsch. Äußerst seltsam - habe sowas noch nie erlebt.
Gleichzeit meldet er, der Projektserver sei "down", während Referenz-Internetzugang aber OK sei. Auch die Diagnose ist falsch, da eine meiner Maschinen erfogreich WUs holt - auf denselben Prefs (die ebenfalls bei diesem Projekt serverseitig komplett anders konfiguriert sind, als sie müßten - aber das ist eben das Ergebnis, wenn man Eigenentwicklungen anstelle des Stadards verwendet) und am selben Netzzugang.
Aber gut, sind halt Rechner weniger am Start.

Log:

Code: Alles auswählen

13.07.2023 15:11:45 |  | choose_project(): 1689253905.545439
13.07.2023 15:11:45 |  | [work_fetch] ------- start work fetch state -------
13.07.2023 15:11:45 |  | [work_fetch] target work buffer: 180.00 + 0.00 sec
13.07.2023 15:11:45 |  | [work_fetch] --- project states ---
13.07.2023 15:11:45 | Gerasim@home | [work_fetch] REC 0.000 prio -0.000 can't request work: scheduler RPC backoff (1545.65 sec)
13.07.2023 15:11:45 |  | [work_fetch] --- state for CPU ---
13.07.2023 15:11:45 |  | [work_fetch] shortfall 720.00 nidle 4.00 saturated 0.00 busy 0.00
13.07.2023 15:11:45 | Gerasim@home | [work_fetch] share 0.000
13.07.2023 15:11:45 |  | [work_fetch] --- state for Intel GPU ---
13.07.2023 15:11:45 |  | [work_fetch] shortfall 180.00 nidle 1.00 saturated 0.00 busy 0.00
13.07.2023 15:11:45 | Gerasim@home | [work_fetch] share 0.000
13.07.2023 15:11:45 |  | [work_fetch] ------- end work fetch state -------
13.07.2023 15:11:45 | Gerasim@home | choose_project: scanning
13.07.2023 15:11:45 | Gerasim@home | skip: scheduler RPC backoff
13.07.2023 15:11:45 |  | [work_fetch] No project chosen for work fetch

Die Problemkiste läuft unter Windows 8.1, eine andere Maschine hat ein Ubuntu LTS 20.04 Linux drauf (dort erwartet man keine WUs, da das Projekt nur Windows mit Apps bedient).
Habe natürlich alles probiert, auch Projektreset, Projekt neu draufziehen, Re-Boot, usw. usf.
Stehe da etwas auf dem Schlauch.

Auch interessant wäre mal zu testen, was eigentlich bei CPU-Benchmarks passiert: Nachdem wir oben von zwei unabhängigen Quellen bestätigt bekommen haben, dass das Anhalten von WUs zur Konversion derselben in Zombies führt, dürfte dasselbe beim Ausführen von Benchmarks passieren, da hierfür sämtliche Prozesse angehalten werden.
Macht man das wiederholt, schmiert einem die Kiste voraussichtlich irgendwann komplett ab - sobald man nur genug Zombies parallel laufen hat.

Michael.

[edit]: Ich vermute, das Projekt läuft gar nicht im Wrapper? Muss ich bei Gelegenheit nochmal genauer checken. Falls dem so ist, erklärt das vermutlich, wieso BOINC von den Zombies nach Anhalten gar nichts mitbekommt.

[yoyo]

Dazu mßte man sich bei einer laufenden WU ansehen was im Slot Verzeichnis liegt.
Wenn kein Wrapper genutzt wird und nur das pure gp.exe, dann wäre das eine Erklärung, dass die Anwendung auf Anweisungen von Boinc (stop, shutdown) nicht reagiert.