Ramanujan schrottet alles

[Michael H.W. Weber]

Sehr kurios. Ich kann mir ehrlich gesagt nicht vorstellen, dass dieses unmögliche, zum Schrotten von WUs führende Verhalten in 12 Jahren BOINC-Entwicklung nicht behoben ist.
Außerdem sind >100 WUs der nach Deiner Interpretation dann ja wieder länger laufenden Sorte schon durchgekaut worden (und im Müll gelandet).
Wie lange wird man warten müssen, bis das autokorrigiert ist?
Was für Werte müßte man manuell in die client_state.xml eintragen?
Ich finde es auch super dreist, dass die Projektleiter seit Tagen keinen Mucks zu den Reports im Discord liefern.

Michael.

[gemini8]

Moin.

Sehr kurios. Ich kann mir ehrlich gesagt nicht vorstellen, dass dieses unmögliche, zum Schrotten von WUs führende Verhalten in 12 Jahren BOINC-Entwicklung nicht behoben ist.

Ich kann mir das schon vorstellen. Boinc ist an vielen Stellen durchaus verbesserungsfähig. Da gab's doch diesen Thread zu zeitgemäßen Verbesserungen und so.

Außerdem sind >100 WUs der nach Deiner Interpretation dann ja wieder länger laufenden Sorte schon durchgekaut worden (und im Müll gelandet).

Ich weiß nicht, welche Hardware du da nutzt. Kann sein, dass dein Rechner einfach durchgängig einen Tick zu langsam ist. Eine Sekunde zu lang wäre ja schon genug, um im Abbruch zu enden.

Wie lange wird man warten müssen, bis das autokorrigiert ist?

Das weiß ich nicht.
Frag Christian - der kennt sich da aus.
Ich nehme an, dass es an der aktuellen Zusammensetzung von Berechnungslängen liegt. Es ist natürlich möglich, dass TRM genauso wie GPUGrid realitätsferne Werte eingebaut hat, die serverseitig nicht korrigiert werden.

Was für Werte müßte man manuell in die client_state.xml eintragen?

Etwas kleineres. Nimm vorne ein, zwei Stellen weg.
Zieh dir einen nicht ganz kleinen Cache, während etwas anderes läuft (z.B. eine PrimeGrid PPS mit Multi-Threading über alle Threads, so dass die TRMs nicht loslaufen), pausiere einen Großteil der TRMs, dann kappe die Internetverbindung, beende den Boinc-Client, passe den Wert an, starte den Client wieder, und schau, was passiert. Wenn die Dinger laufen, lasse auch die pausierten TRMs los. Und wenn das so läuft, stelle die Internetverbindung wieder her, um die fertigen Teile hochladen zu lassen.
Und ich bin gespannt, ob der Server den Wert dann wieder zurücksetzt.
Sollte das der Fall sein, setz eine VM auf, sperre die Dinger ein, und lasse sie jeweils nach dem vorstehenden Verfahren laufen - es sei denn, dass dieser 'neue' Rechner keine Probleme hat.
Oder nimm statt einer VM einen zweiten Client, um auszuprobieren, ob der weniger Probleme hat.

Ich finde es auch super dreist, dass die Projektleiter seit Tagen keinen Mucks zu den Reports im Discord liefern.

Bei GPUGrid abgeschaut.
Erwähnte ich schon einmal, dass ich PrimeGrid mag?
IMMER Admins im Discord, die zeitnah reagieren, wenn man sie pingt. Und das Forum funktioniert auch gut.
Warte: Das gesamte Projekt funktioniert gut.

[Michael H.W. Weber]

Warum werden dann einzelne lang laufende Tasks als OK anerkannt, die große Mehrheit aber nicht? Das passt doch nicht ins Erklärungsschema. Auch gibt es mehr als einen Fehlermeldungstyp.

Michael.

[Michael H.W. Weber]

Ich habe das Projekt natürlich im Laufe meiner Problemlösungsversuche auch per Reset und durch Ab- und Wiederanmelden auf den Clientmaschinen zur Raison zu bringen probiert. Sollten dabei nicht die Einträge in der client_stat.xml verschwinden?
Die Idee mit den Laufzeiten habe ich den Projektbetreibern auch noch per Discord zukommen lassen.

Michael.

[gemini8]

Warum werden dann einzelne lang laufende Tasks als OK anerkannt, die große Mehrheit aber nicht? Das passt doch nicht ins Erklärungsschema. Auch gibt es mehr als einen Fehlermeldungstyp.

Wie lang sind sie denn, wenn sie durchlaufen?

[Michael H.W. Weber]

Warum werden dann einzelne lang laufende Tasks als OK anerkannt, die große Mehrheit aber nicht? Das passt doch nicht ins Erklärungsschema. Auch gibt es mehr als einen Fehlermeldungstyp.

Wie lang sind sie denn, wenn sie durchlaufen?

...ca 45 Min unter Linux und 1:20 Std unter Windows.
Zwischen erfolgreich absovierten und geschrotteten WUs gibt es aber keine Laufzeitdifferenz. Das ist ja das kuriose. Wenn die nun alle nach 10 Min. abgebrochen würden, aber nein.

Michael.

[gemini8]

Habe mich ein wenig durch die Gegend geklickt.
Während ich 0 Fehler habe, hängen an meinen ausstehenden Aufgaben teilweise anderer Leute Problemkinderchen.
Immer Fehler der gleichen Art wie bei dir - nur mit anderen Zahlen.

[Michael H.W. Weber]

Habe mich ein wenig durch die Gegend geklickt.
Während ich 0 Fehler habe, hängen an meinen ausstehenden Aufgaben teilweise anderer Leute Problemkinderchen.
Immer Fehler der gleichen Art wie bei dir - nur mit anderen Zahlen.

Könntest Du bei Gelegenheit mal in Deiner client_State.xml nachsehen, was dort im Zusammenhang mit Ramanujan steht?
Bei mir ist es inzwischen so, dass zumindest die Linuxkiste langsam zunehmend valide Tasks abliefert.
Manche Dinge erledigen sich eben durch Aussitzen, wie Helmut Kohl schon wußte...

Michael.

[gemini8]

Ca. 2.3B Flops.

[Michael H.W. Weber]

Beide Maschinen liefern nun ohne jeglichen Eingriff meinerseits wieder nur valide Tasks ab.
Vom Projekt wurde meines Wissens kein Eingriff kommuniziert.
Wird also möglicherweise wieder passieren, wenn die den WU-Typ ändern sollten?

Michael.

[gemini8]

Wir werden sehen.

[Michael H.W. Weber]

Wir werden sehen.

...genau das möchte ich eigentlich nicht. Also - es nochmal sehen müssen...

Michael.