12. Pentathlon 2021 - NFS@Home (Sprint)

Das war schon immer so bei großen Bunkerwürfen und (für diese) schwacher Serverhardware. Also dürfen wir zukünftig auch keine fetten Bunker mehr fallen lassen oder was?
Gegen normale Bunkerwürfe kann sich der Server wehren wenn es ihm zu viel wird. Gegen Bunkerwürfe "von innen heraus" nicht.

Ja logo, die haben das mit einmal hochgeladen und gemeldet, hätte ich auch so gemacht.
Nein, das haben sie eben nicht! Lies bitte nochmal meine Erläuterung!
Hab ich und ist exakt das gleiche. Ich verstehe nicht, wo der Punkt differieren soll. Die Sache ist doch ganz einfach, die haben alles hochgeladen und dann gemeldet, als es noch kein Problem war und seitdem ist der Server eben damit beschäftigt (und es wurde dann für alle zum Problem).
Wenn die einzelnen Module des Boinc Servers keine eigene IP haben, kann man da unmöglich von außen gezielt etwas kaputt schießen, würde ich sagen.
 
warum habt ihr nicht bei TAAT im Forum mitgelesen, die haben sich bestimmt darüber unterhalten^^
Wozu? Es war doch (mir und den meisten anderen) klar, dass da heute noch was kommt. Deswegen haben sie sich heute Vormittag schon stundenlang in der Shoutbox gestritten, ob es unethisch ist 1250 CPU-Kerne in der Cloud zu mieten für eine Pentathlon-Disziplin oder nicht.
Wenn die einzelnen Module des Boinc Servers keine eigene IP haben, kann man da unmöglich von außen gezielt etwas kaputt schießen, würde ich sagen.
Wie kommst Du nur immer wieder darauf, dass jemand gezielt etwas kaputt schießen wollte?! Das sagt niemand! Ich sage nur, dass es ein Unterschied ist, ob man "normale" Bunker wirft, also ab einem bestimmten Zeitpunkt anfängt hochzuladen und fertig zu melden, oder ob man über 6 Tage hinweg hochlädt und dann kurz vor Ende alles auf einmal fertigmeldet. Dass das kein gezieltes Kaputtschießen ist, ist klar, aber es stellt zumindest sicher, dass ihr Kram abgearbeitet wird und der aller anderen nicht. Was ihnen ja auch gelungen ist.

Wie gesagt: ich versteh nur nicht, wie sie es hier gemacht haben, nachdem es bei NFS keinen separaten scheduler-Host gibt.
 
Zuletzt bearbeitet:
Nur mal so aus Interesse, was kostet es denn 1250 CPU-Kerne in der Cloud zu mieten ? *kopfkratz
 
@cyrusNGC_224
Du verstehst nicht wirklich worum es dabei geht, oder?
Die WUs werden auf den Server geladen aber die Fertigmeldung blockiert.
Am Ende werden nur noch die Fertigmeldungen rausgeschickt und die Arbeit von Tagen innerhalb von Sekunden freigesetzt weil die komplette Verzögerung durch den Upload entfällt. Dem entsprechend sind dann die weiteren Verarbeitungsschritte dann überlastet und der Server macht dicht weil er keine weiteren WUs mehr entgegennehmen kann. Das findet letztendlich alles Server intern statt.
Wenn der Server dann noch mit Anfragen bombardiert wird damit andere ihre WUs noch loswerden geht irgendwann auch die Daten Verbindung zum Server den Bach runter.
 
Der gesamte Hochladevorgang bei BOINC ist intransparent.
Das gehört für solche Wettbewerbe aufgedröselt.
Sonst wird das nichts mehr.
Jedes mal entsteht Unfrieden deswegen.

Technisch sollte sich die Veranstalter hier etwas überlegen und mit den Projekten oder mit der BOINC-Truppe selbst hier etwas ausarbeiten.

Klar ist, dass man viele Projekte nicht einfach mit so einem Wettbewerb überfallen kann.
Das gehört ordentlich geplant und vorbereitet, sodass serverseitig keine Engpässe zum Nachteil der Teilnehmer entstehen können.
Gut zureden hilft anscheinend nicht, denn es kommt immer wieder vor, dass so eine Scheiße passiert.

Schade.
 
Eben, manche Anbieter stellen auch stundenweise Rechenleistung zur Verfügung.
 
Wenn ich sehe, dass ALLE Zahlen der anderen Teams zusammenbrechen, dann ist das für mich auch das Zeichen, dass diese ebenso wie wir nichts hochladen konnten.
Oder warum sollten alle auf einmal plötzlich nicht mehr wollen?
Schau doch mal in dein NFS-Konto, das dürfte sicherlich so aussehen wie hier:
1621287745027.png
Ein Quorum 1-Projekt hat eigentlich kein Pending, dass eine Überprüfung ausstehend sein kann. Das passierte hier nur, weil der Validator die vielen zurückgemeldeten WUs nicht auf valid setzen konnte und die Punkte vergeben konnte.
Hochladen ist nur der erste Schritt, auf dem Server selbst ist noch der Schritt mit dem Validator zu erledigen, ehe es Punkte gibt.
Das heißt, alle Teams haben weiterhin so wie wir relativ frische NFS gerechnet, vielleicht hochgeladen bekommen, aber beim Validator mussten erst noch ältere validiert werden.

@Nero24 Es werden sehr alte WUs gewesen sein mit MHD 17.5. oder so in dem Dreh.
1621287972734.png
 
Aber das Zeug das schon hochgeladen auf dem Server lag und nur noch fertig gemeldet werden musste, das kann er nicht abblocken.
Das könnte der Server aber vermutlich auch irgendwie so hinbekommen, dass er eine interne Warteschleife dafür hat und nur so viel abarbeitet, dass die anderen Funktionen nicht überlastet werden.
Wobei dann zwar alle noch hochladen könnten, aber die Wartezeit aufs Ergebnis wird eher noch länger.
 
Wobei dann zwar alle noch hochladen könnten, aber die Wartezeit aufs Ergebnis wird eher noch länger
Ein Projekt hat für einen Wettbewerb ausgerüstet zu sein.
Wenn sie es nicht schaffen für alle die gleichen Bedingungen dauerhaft bereit zustellen ohne das Ergebnis zu verfälschen, dann sind sie nicht dafür geeignet.
So einfach ist das.

Ein F1 Rennen kann ich auch nicht auf nen Feldweg austragen.
 
Bei Amazon könntest du was schnuckeliges mit 400 Threads und 1 TB RAM für schlappe 30k bekommen...für eine Woche
 
@tomturbo
In meinen Augen gäbe es da eine recht einfache Lösung die man den Projektbetreibern nahe legen sollte.
Nach spätestens 24 Stunden verfallen hochgeladene aber nicht fertig gemeldete WUs oder müssen dann erneut hochgeladen werden.

Ersteres wäre natürlich lustig weil man dann diejenigen dann meist recht einfach rausfinden könnte weil sie dann am lautesten schreien. *oink*

@Pegasushunter
Ich kenne natürlich keine aber lasse es ein paar hundert oder auch 1-2 tausend € pro Tag kosten, ist immernoch deutlich billiger als die Anschaffung der Hardware.
 
warum habt ihr nicht bei TAAT im Forum mitgelesen, die haben sich bestimmt darüber unterhalten^^
Wozu? Es war doch (mir und den meisten anderen) klar, dass da heute noch was kommt. Deswegen haben sie sich heute Vormittag schon stundenlang in der Shoutbox gestritten, ob es unethisch ist 1250 CPU-Kerne in der Cloud zu mieten für eine Pentathlon-Disziplin oder nicht.
Wenn die einzelnen Module des Boinc Servers keine eigene IP haben, kann man da unmöglich von außen gezielt etwas kaputt schießen, würde ich sagen.
Wie kommst Du nur immer wieder darauf, dass jemand gezielt etwas kaputt schießen wollte?! Das sagt niemand! Ich sage nur, dass es ein Unterschied ist, ob man "normale" Bunker wirft, also ab einem bestimmten Zeitpunkt anfängt hochzuladen und fertig zu melden, oder ob man über 6 Tage hinweg hochlädt und dann kurz vor Ende alles auf einmal fertigmeldet. Dass das kein gezieltes Kaputtschießen ist, ist klar, aber es stellt zumindest sicher, dass ihr Kram abgearbeitet wird und der aller anderen nicht. Was ihnen ja auch gelungen ist.

Wie gesagt: ich versteh nur nicht, wie es hier gemacht haben, nachdem es keinen separaten scheduler-Host gibt.
Nachdem Projektseitig kein eigener (soweit für uns erkennbar) Scheduler host existiert den man blocken kann, muss man das Problem wohl kreativer angehen.

Ich habe schlicht in der client_state.xml (BOINC gestoppt) die Scheduler URL von escatter auf pscatter geändert, schon funktioniert die Abfrage / Fertigmeldung nicht mehr:
Code:
Mon 17 May 2021 23:52:24 CEST | NFS@Home | Requesting new tasks for CPU
Mon 17 May 2021 23:52:24 CEST | NFS@Home | [http] HTTP_OP::init_post(): http://pscatter11.fullerton.edu/nfs_cgi/cgi
Mon 17 May 2021 23:52:25 CEST | NFS@Home | [http] [ID#1] Info:  17 bytes stray data read before trying h2 connection
Mon 17 May 2021 23:52:25 CEST | NFS@Home | [http] [ID#1] Info:  Could not resolve host: pscatter11.fullerton.edu
Mon 17 May 2021 23:52:25 CEST | NFS@Home | [http] [ID#1] Info:  Closing connection 3
Mon 17 May 2021 23:52:25 CEST | NFS@Home | [http] HTTP error: Couldn't resolve host name
Mon 17 May 2021 23:52:25 CEST |  | Project communication failed: attempting access to reference site

Hochladen müsste aber weiterhin klappen, da es dafür ja die separate upload_url gibt.
 
Die Frage ist, ob der Anbieter 100% Last auf der CPU über die Dauer auch in den AGB hat.
 
In meinen Augen gäbe es da eine recht einfache Lösung die man den Projektbetreibern nahe legen sollte.
Nach spätestens 24 Stunden verfallen hochgeladene aber nicht fertig gemeldete WUs oder müssen dann erneut hochgeladen werden.
Ja die Verfallsdauer stark zu reduzieren ist sicher der beste Weg um alleine das blöde Megabunkern zu unterbinden.
 
Also alle Lotto spielen und wer 7 Richtige hat, lässt den nächsten Pentathlon in der Cloud stattfinden , langweilig aber sehr entspannend *g* Pentathlon für Faule *chatt*
 
Mit einer kleinen Spendenaktion käme da schon ordentlich was zusammen, denke ich.
 
Man könnte ja zig Instanzen anlegen und die dann rechtzeitig auf den eigenen PC zurück holen um sie dann abzuschicken :LOL:
 
Nach spätestens 24 Stunden verfallen hochgeladene aber nicht fertig gemeldete WUs oder müssen dann erneut hochgeladen werden.
Ich finde ohnehin diese Trennung von Hochladen und Melden etwas schräg. Klar, für einen upload von 1000 WUs am Stück ist ein gemeinsames Melden sinnvoll. Aber dann brauchts auch keine 24h, sondern eine Stunde als Verfallsdatum sollte auch langen.

PS: Schade, dass die Tipps und scripte für alle sichtbar sind.
 
Mit einer kleinen Spendenaktion käme da schon ordentlich was zusammen, denke ich.
Hm, ja, die Frage ist: wollen wir das wirklich? :o Eigentlich sollte der Penta ja ein Wettkampf sein, um zu sehen, was UNSERE Hardware so drauf hat, nicht was man sich irgendwo günstigst mieten kann. *noahnung*
 
Mit der Schüttelbüchse aufm Alex... Bitte spenden Sie für den Penta-Cloudathlon im Jahr 2022. Der Ruhm ist Ihnen gewiss. Garantiert mit stündlich aktualisierten Meldungen aus der Shoutbox *chatt* *rofl*
 
Mit Umarmungen lockt man ja heute auch keinen mehr als Belohnung hinterm Ofen vor...
 
Zurück
Oben Unten