Stiwi hat geschrieben: 11.06.2020 15:17
Ich hab jetzt erst nachgelesen wie das beim Wanless Mersenne +2 ablief.
Also das ist echt das erste Projekt wo ich sage bei dem Betreiber werde ich niemals eine WU rechnen oO
JagDoc hat geschrieben: 11.06.2020 16:10
Das ist ein kleines Projekt bei dem normal sehr wenig User rechnen und für den Sprint nicht geeignet ist.
Was soll der Betreiber denn machen wenn sich plötzlich viele Rechner tausende WUs ziehen und der Server total überlastet ist?
Er hat bis auf Datenbankbasierte Webseiten und Upload/Download Server alles gestoppt.
Die fertigen WUs wurden hochgeladen und konnten nur nicht gemeldet werden.
Seit heute läuft es wieder normal und die längst abgelaufenen hochgeladenen WUs wurden nach dem melden gutgeschrieben.
Wenn ich die Posts durchlese ist es auch verständlich wenn der Admin nicht mehr auf die Posts nicht mehr antwortet.
Stiwi hat geschrieben: 11.06.2020 17:30
So wie ich es verstanden habe gab es dann für keine WU mehr credits weil die alle/meisten nach Ablaufdatum hochgeladen werden konnten, bzw. was ja noch schlimmer ist sie mussten von einem weiteren Rechner erneut gerechnet werden?
Da hätte er die Deadline hochsetzen können, aber er hat ja nicht mal (zumindest liest es sich für mich so) versucht für das Problem eine Lösung zu finden.
Sowas finde ich halt ärgerlich, auch wenns mich nicht betroffen hat.
Dass der Server nicht für Sprints usw. geeignet ist hat man gesehen, da haben dann auch eher die Organisatoren von Formular Boinc das Problem dass sie sich nicht wirklich mit den Projekten absprechen bzw. überhaupt einmal nachfragen ob das OK ist
Aber wenn ich nur nen "schwachen" Server habe wieso gibt man dann so viele WUs raus? Kann man das bei Boinc nicht konfigurieren? Falls das nicht geht sollte man vielleicht mal bei Github ein Ticket dafür einstellen. Wenn ich weiß mein Server kann max 100.000 Wus ab dann macht es wenig sinn 200.000 Wus in progress zu haben.
Edit: ich sehe gerade dass keine weitere Wus bisher gesendet wurden. Wenn die wirklich noch alle akzeptiert werden dann ist das doch alles gut. Hätte er aber auch zur Beruhigung schreiben können dass es so abläuft
Und ja manche Leute haben sich im Forum echt im Ton vergriffen.
Wir rechnen hier für (teils pseudo-)wissenschaftliche Projekte. Der übliche Betreiber setzt ein Projekt auf, die Anzahl der Unterstützer wird größer, und das Projekt stellt irgendwann fest, dass es Maßnahmen ergreifen muss, um mit der gestiegenen Anzahl an Usern und Rechnern klarzukommen.
yoyo kann dir anschaulich erzählen, dass Zalando nicht mehr funktioniert, wenn ein Admin, der über ein größeres Rechenzentrum verfügt, eine quasi-DoS-Attacke auf einen kleinen Projektserver fährt, indem er das Rechenzentrum auf einen Schlag auf das Projekt loslässt. Genau das passiert häufig, wenn ein sonst wenig beachtetes Projekt Opfer eines Sprints wird. Dieses Szenario wird durch neue, schnellere Computer mit immer mehr Threads noch verschärft, weil der Turnaround immer kürzer wird, und selbst bei einer gleichbleibenden Computeranzahl immer mehr Aufgaben benötigt werden, um diese auszulasten.
Wenn man jetzt mal überschlägt, dass bei den üblicherweise bunkernden Crunchern diese neueren Maschinen stehen, die möglicherweise seit dem letzten Jahr nicht nur doppelt-, sondern vier- oder sogar achtfach so viele Aufgaben wie bisher einheimsten, dann wäre es möglich, dass ein Admin erst einmal mehr Aufgaben herausgibt, um den Hunger nach Arbeit zu stillen, um dann festzustellen, dass sein Server Probleme bekommt.
Ich möchte darauf hinweisen, dass ich das tatsächliche Szenario nicht kenne, aber das gerade vorgestellte ist durchaus denkbar und könnte auf weitere Projekte zukommen.
Selbst ein völlig stabil laufendes Projekt wie PrimeGrid hatte bei einem der letzten Wettkämpfe Probleme, weil die neuen ZENs und High-End Intels die kurzen Aufgaben so schnell zurückgegeben haben, dass auch hier ein DoS-Effekt auftrat.
*edit*
@yoyo:
Es heißt Saskatchewan.
*end edit*
