13. Pentathlon 2022: Hindernislauf ex Marathon (Universe@Home)

[cologne46]

Womit eigentlich?

Dem Zustimmen, dass ihr Projekt bei einer Challenge gerechnet wird.

 

[MagicEye04]

Achso. Naja, auf diese einzelnen Eingeschnappten und verbal Entgleisten würde ich ehrlich gesagt auch keine Rücksicht nehmen.
Die Challenges sind doch lange vorher bekannt. Dann rechnet man halt in dieser Zeit nicht. Wenn gerade Wartung ist, kann man auch nix abliefern.

Ich fand aber die Idee eines Spendenkontos nicht schlecht. Das sollte wirklich mal überdacht werden. Anstatt noch mehr Geld in die eigene Hardware zu stecken, die dann untätig Däumchen dreht, würde ich da eher ab und zu einen Schein an die wenigen noch verbliebenen Naturwisschenschaftsprojekte stecken, damit die den Pentathlon besser überstehen.

Mal abgesehen davon, die aktuellen WUs sind in deutlich weniger als 1h durchgerechnet. Es würde vielleicht schon helfen, wenn die WUs einfach 10 so lange laufen auf den schnellen Rechnern. Oder wenn alles in einer Datei übertragen wird.

 

[cologne46]

Bei der Berechnungsdauer bin ich bei dir. Habe mich auch schon gefragt warum nicht einfach zwei Wochen vor dem Penta die Laufzeit deutlich verlängern damit weniger Dateien hoch und runter trasnferiert werden müssen.

Das Packen der mehreren Dateien auf dem Client Rechner wäre möglich, müßte dann auf dem Server aber wieder entpackt werden.

Obviously we can send to volunteers another executable file which will pack result files together but... This doesn't have any sense as the files must be unpacked back on server which will cause in more disk operations and overall server load (but single result files are zipped on client side).

 

[FritzB]

Mal abgesehen davon, die aktuellen WUs sind in deutlich weniger als 1h durchgerechnet. Es würde vielleicht schon helfen, wenn die WUs einfach 10 so lange laufen auf den schnellen Rechnern. Oder wenn alles in einer Datei übertragen wird.

Damals die SETI-Classic Dinger liefen auf dem 486er oder K6 auch mehrere Tage. Bei SiDock gibts ja auch Langläufer. Ob das bei jedem Projekt möglich ist, weiß ich nicht. Bei Rosetta bräuchte man im Zweifel bei 5+5 Tagen nur ~7 WUs pro Kern bei 36 Std Laufzeit.

Was großflächig kommuniziert werden müsste ist, dass es besser ist (sofern möglich) nur den scheduler zu blocken und nicht den kompletten Upload. Dann verteilt sich das besser. Hatte Krystoph (weiß nicht genau wie er geschrieben wird) für Universe bestätigt.

 

[herby44]

Letztes Jahr mit Sidock als Marathon Projekt gab es solche Probleme nicht, lange Laufzeit und kurze Haltbarkeit.

 

[skelletor]

Meine restlichen vom Laptop hat er ohne Script heute Vomittag alle hoch bekommen.
Sollte also wieder halbwegs funktionieren.

 

[Sightus]

Bei mir ist fast alles hochgeladen. Komme somit sich fast genau 50. Mio Credits während des Pentathlon, auch wenn nur 40. Mio davon rechtzeitig online waren.

 

[skelletor]

Echt schade, das wäre schon die Hälfte unseres Rückstands gewesen.
Aber hätte wäre wenn... Meine letzten 389 im Pending nehmen langsam ab...

 

[olsen_gg]

.........

Mal abgesehen davon, die aktuellen WUs sind in deutlich weniger als 1h durchgerechnet. Es würde vielleicht schon helfen, wenn die WUs einfach 10 so lange laufen auf den schnellen Rechnern. Oder wenn alles in einer Datei übertragen wird.

Kann ich bestätigen. Meine laufen mal wieder in etwas über 1/2h durch.
Uploadstau kann ich nicht mehr bestätigen, hier läufts einfach so durch, Bunker auf 0,5+0 Tage gestellt und fertig.
Aber nach den negativen Diskussionen hier wegen der Bunkerei habe ich ja auch nur noch einfach so durchlaufen lassen. Vielleicht liegts ja daran.

BTW: Ich lasse noch ein paar Tage Universe laufen, möchte gern noch die 10 Millionen voll machen.
[automerge]1653029731[/automerge]

.......
Was großflächig kommuniziert werden müsste ist, dass es besser ist (sofern möglich) nur den scheduler zu blocken und nicht den kompletten Upload. Dann verteilt sich das besser. Hatte Krystoph (weiß nicht genau wie er geschrieben wird) für Universe bestätigt.

Ja. Scheint aber so, dass einige hier das nicht glauben wollen, trotz dieser Bestätigung. Aus irgendeinem Grunde geht die Diskussion darüber immer wieder los. Meine Entscheidung steht fest. Ich bunkere nicht mehr und fertig.

 

[sompe]

.......
Was großflächig kommuniziert werden müsste ist, dass es besser ist (sofern möglich) nur den scheduler zu blocken und nicht den kompletten Upload. Dann verteilt sich das besser. Hatte Krystoph (weiß nicht genau wie er geschrieben wird) für Universe bestätigt.

Ja. Scheint aber so, dass einige hier das nicht glauben wollen, trotz dieser Bestätigung. Aus irgendeinem Grunde geht die Diskussion darüber immer wieder los. Meine Entscheidung steht fest. Ich bunkere nicht mehr und fertig.

Das Problem ist das dies nur die halbe Wahrheit ist denn jede WU die hochgeladen wird muss auch runtergeladen werden.

Bei dem Hindernislauf wird das schnell toxisch weil nicht mehr einzelne Teams/User Zeitversetz ihren Bestand hochjagen/freigeben und dann selbstverständlich auch noch neue WUs benötigen sondern alle auf einmal und das auch noch in einem begrenzten Zeitraum.
Damit kommt also noch ein weitere Punkte hinzu die den Berg an Anfragen nochmal zusätzlich um ein Vielfaches höher ausfallen lassen.

Wird der Server dann auch noch wie hier gesehen mit zusätzlichen Anfragen überschüttet um eine höhere Chance hat ein größeres Stück vom Kuchen der Server Kapazität abzubekommen (hier passen die ddos Vergleiche durchaus) dann bekommt er noch nicht einmal Zeit sich zu erholen, womit wir praktisch Punkt 4 hätten.
Die hatte man im laufe der Disziplin nach den Bonus Tagen nachdem die Folterknechte des Servers ihre Bunker wieder verschlossen hatten und wieder Ruhe gaben aber diese Phase blieb am Ende komplett aus weil jeder seine WUs nochmal unbedingt loswerden wollte und das tat was so viele andere bisher so erfolgreich machten. den Server mit zusätzlichen Anfragen zuschei**en um zum Ziel zu kommen.
Folglich wurde der ursprüngliche Teil der Diskussion (Art des Uploads) praktisch irrelevant weil die Hämmer Phase weiterhin bestehen blieb und sich wegen des bevorstehenden Endes der Disziplin vermutlich eher noch verschlimmert hatte.
Erst nach dem Rennen, als wieder alle Folterknechte Ruhe gaben, erholte sich der Server wieder im erwarteten Zeitraum.

Damit entpuppte sich die neue Disziplin letztendlich als massiver Verdrängungswettbewerb weil folglich alle anderen auf der Strecke blieben und ich hoffe ernsthaft dass das nicht so bleibt.

 

[Ritschie]

In der Host Datei geblockt?

... um die letzten hartnäckigen 1637 WUs rauszukehren, musste ich komischerweise die cc-config wieder rauslöschen - seitdem läuft's.

Wer also immernoch keine WUs hochgeladen bekommt: cc-config löschen!

Gruß
Ritschie

 

[MagicEye04]

Wird der Server dann auch noch wie hier gesehen mit zusätzlichen Anfragen überschüttet um eine höhere Chance hat ein größeres Stück vom Kuchen der Server Kapazität abzubekommen (hier passen die ddos Vergleiche durchaus) dann bekommt er noch nicht einmal Zeit sich zu erholen, womit wir praktisch Punkt 4 hätten.
Die hatte man im laufe der Disziplin nach den Bonus Tagen nachdem die Folterknechte des Servers ihre Bunker wieder verschlossen hatten und wieder Ruhe gaben aber diese Phase blieb am Ende komplett aus weil jeder seine WUs nochmal unbedingt loswerden wollte und das tat was so viele andere bisher so erfolgreich machten. den Server mit zusätzlichen Anfragen zuschei**en um zum Ziel zu kommen.
Folglich wurde der ursprüngliche Teil der Diskussion (Art des Uploads) praktisch irrelevant weil die Hämmer Phase weiterhin bestehen blieb und sich wegen des bevorstehenden Endes der Disziplin vermutlich eher noch verschlimmert hatte.
Erst nach dem Rennen, als wieder alle Folterknechte Ruhe gaben, erholte sich der Server wieder im erwarteten Zeitraum.

Zum Melden reicht genau eine Anfrage an den Server. Wenn man nicht durchkommt, vielleicht noch ein paar mehr.
Bei der langen Haltbarkeit der WUs hätten man sich eigentlich bereits am Anfang komplett damit eindecken können. Hab ich nicht gemacht, weil ich dachte, es kommt doch mindestens noch eins, oder sogar 2 weitere CPU-Projekte. Auch mit Einsteinen habe ich mich nicht übermäßig eingedeckt und da war es auch gut so.

 

[sompe]

Zum Melden reicht genau eine Anfrage an den Server. Wenn man nicht durchkommt, vielleicht noch ein paar mehr.

Das ändert aber am Rest nichts. Die WU muss dennoch vorher runter- und dann wieder hochgeladen werden, für gewöhnlich in mehreren Dateien und für jede einzelne ist mindestens eine Anfrage erforderlich.
Es geht eben nicht darum den Upload über einen möglichst großen Zeitraum zu verteilen und dann zusammen an einem unbestimmten Zeitunkt zu melden (das wäre in der Tat die schonendere Variante) sonder ALLE User wollen ihre WUs zu einem fixen und nicht an unterschiedlichen Zeitpunkten abschicken UND neue beziehen und spätestens dann treten sich alle gegenseitig auf die Füße weil die Bunker Sprenger natürlich nicht nur die gerade benötigten WUs sondern den Bedarf von Tagen ziehen wollen. Sobald dann der Server ins Stocken gerät wird er auch von ebenso vielen zusätzlichen Anfragen überflutet und damit das Problem noch verschlimmert weil das ja unbedingt JETZT sein muss unzwar bei allen Usern die nicht darauf pfeiffen.

Mein persönlicher, zumindest beobachteter, Rekordhalter war eine 20 Byte Datei mit einem Upload Zeit von über einer halben Stunde (obwohl die Rechner Zeitweise aus waren) und nur allso oft scheitert es nicht am Upload an sich sondern an der Bestätigung vom Server das er auch abgeschlossen ist und beim nächsten Versuch beginnt man wieder bei 0 bis die Datenübertragung irgendwann erfolgreich abgeschlossen ist und die Meldung erfolgen kann die dummer weise ebenfalls X mal scheiterte bis sie irgendwann endlich mal durch war. Wie gesagt, beim Download neuer WUs beginnt das Elend erneut.

Bläst man für diesen Vorgang aber hunderte bis tausende Verbindungsversuche in Rekordzeit raus um an sein Ziel zu kommen kann wofür normalerweise nur eine Hand voll Meldungen erforderlich sind kann sich jeder selbst ausmalen was das für den Server bedeutet.
Bei einzelnen Usern mag das verschmerzbar sein aber bei so festen Zeitgrenzen wie es bei dieser Disziplin zwangsläufig der Fall sind wären das potentiell alle Teilnehmer sobald der Datenstrom ins stocken gerät.
Keiner der bei Verstand ist wird den Server auf eine so massive Abweichung vom Normalzustand auslegen und schon schießen sich alle mit dieser Praxis selbst und anderen ins Knie. Das Problem ist eben vor allem Anzahl der User die diese Methoden nutzen um sich über die Masse an Anfragen ans Ziel zu kommen....wie bei einem ddos Angriff eben auch.

Die lange Haltbarkeit ist zudem wegen der kurzen Laufzeit und der limitierten WU Zahl fast schon nebensächlich. Meine beiden Ripper hatten irgendwas um die 1000 WUs bekommen und das reichte keinen Tag, beim 64 Kerner noch nicht einmal über den Vormittag hinaus.
Um deinen Vorschlag den kompletten WU Bedarf zu Beginn zu holen umzusetzen hätte ich zu Beginn also allein für den (ca. 170 WUs pro Stunde) fast 60.000 WUs ziehen müssen und jetzt rechnen wir nochmal alle Rechner der gesammten Teilnehmer zusammen.....

 

[JagDoc]

Es geht eben nicht darum den Upload über einen möglichst großen Zeitraum zu verteilen und dann zusammen an einem unbestimmten Zeitunkt zu melden (das wäre in der Tat die schonendere Variante)

Das genau ist der Fall wenn mit dem Hosteintrag das Melden unterbunden wird.
Die WUs werden sofort hochgeladen wenn sie fertig sind, genau wie wenn der Rechner durchläuft.
Nur das Melden erfolgt dann später mit einer/ein paar Anfragen.
Wenn man sich am Anfang gleich mit genug WUs in ein paar Instanzen eindeckt, braucht man auch keine neuen holen.
Damit ist der Server am wenigsten belastet.

Das Problem sind diejenigen die sich den Rechner mit WUs vollmachen und bei abgeschaltetem Netzwerk rechnen.
Die laden dann alles auf einmal hoch und wollen gleichzeitig wieder neue WUs.

 

[MagicEye04]

ALLE User wollen ihre WUs zu einem fixen und nicht an unterschiedlichen Zeitpunkten abschicken UND neue beziehen

Darum ja gleich am Anfang komplett eindecken.

eine 20 Byte Datei

Da sehe ich ehrlich gesagt das größte Verbesserungspotential. Ist zwar schön, dass das Projekt an einer 1GBit-Leitung hängt - aber Bandbreite ist nun wirklich in dem Fall vernachlässigbar.

 

[sompe]

@JagDoc
Eben nicht denn durch die Bonusrunden gab es 4 fixe Zeitpunkte wo alle ihre WUs loswerden und nach Möglichkeit auch neue ziehen wollten. Eben weil der WU Durchsatz durch die vergleichsweise kurzen Laufzeiten so hoch ist und am Ende legen alle nochmal richtig los um das rechtzeitig weg zu bekommen was bei der letzten Bonusrunde liegen blieb. Offensichtlich wurde der Server nach der letzten Bonusrunde so mit Anfragen zugespämt das er sich bis zum Ende nicht mehr erholte und erst danach wie nach den ersten beiden Bonusrunden im erwarteten Zeitraum (Nachmittag) normalisierte.
Diese Disziplin war ganz einfach aufgrund des Userverhaltens für den Server toxisch. Hätten alle wie bisher einfach nur durchgerechnet und einzelne an unterschiedlichen Zeitpunkten Bunker gezündet....
[automerge]1653078434[/automerge]

ALLE User wollen ihre WUs zu einem fixen und nicht an unterschiedlichen Zeitpunkten abschicken UND neue beziehen

Darum ja gleich am Anfang komplett eindecken.

Wenn man eine Lebensaufgabe daraus machen will....
Beim Hochladen hatte ich für ca. 2000 WUs eine gute Stunde gebraucht. Nimmt man das als Basis dann wäre ich bei ca. 100.000 zu erwartenden WUs auf über 2 Tage Downloadzeit i einem Zeitraum gekommen an dem ALLE ihre WUs ziehen würden. Da der 16 und der 8 Kerner aber lediglich 500 WUs bekamen wäre das auf wieviele Instanzen hinausgelaufen? 150-200 und das ohne zu wissen wieviele Rechner ich in dem Zeitraum darauf abstellen kann und dann die überschüssigen WU Massen abbrechnen oder nachrechnen müßte?
Mal ehrlich, ich habe auch noch anderes zu tuen....

eine 20 Byte Datei

Da sehe ich ehrlich gesagt das größte Verbesserungspotential. Ist zwar schön, dass das Projekt an einer 1GBit-Leitung hängt - aber Bandbreite ist nun wirklich in dem Fall vernachlässigbar.

Die Bandbreite ist hinfällig wenn die Masse derBerg an Anfragen nicht mehr rechtzeitig verarbeitet und beantwortet werden kann. Soweit mir bekannt ist das auch die Funktionsgrundlage eines ddos Angriffs.

 

[MagicEye04]

Ich hatte vor allem die Anzahl der nutzbaren Kerne hochgeschraubt. Daher bin ich mit recht wenig Instanzen ausgekommen. Und Instanzen lassen sich automatisiert anlegen.

 

[sompe]

Das ändert nur nicht an den 2 Tagen Vorbereitungszeit die dann ALLE nutzen müßten und vorhersehbar dann zu welchen Ergebnissen führen würden?

 

[MagicEye04]

Entweder ist es mir wieder entfallen, oder es gab keine Probleme mit dem Server in den Tagen vor dem Startschuss.

 

[sompe]

Und nun rate mal warum...
Wäre mir jedenfalls neu wenn da alle die Arbeit für 2 Wochen gezogen hätten wie es deinem Vorschlag entsprechen würde.
Das funktioniert nur so lange wie es nur wenige machen denn dann hält sich die Last für den Server in Grenzen weil es in der Masse der normal nutzenden User untergeht.
Deine Elektroinstallation funktioniert ja auch nur solange du nicht alle Anschlüsse gleichzeitig maximal belastest und niemand wäre so Grenzdebil die Hauselektrik darauf auszulegen weil extreme Geldverschwendung.

 

[Skillz]

One wonders somehow how TAAT manages to increase the output shortly before the end and get it into the ranking and drop off so strongly directly after the end of the race.

I'd be really interested in how they do it.

Download tasks early, the older the task the higher it's chances of being validated. The older the task, the higher it's priority is on the server when being validated. First out, first validated when going back in.

Upload tasks as soon as your "bunker" is done. But do NOT report them.

This allows you to skip the uploading when it matters (IE: When everyone else is uploading) and just hit the "Report" button (Basically update the project on the host) and all the tasks you uploaded days before will be reported at that time .

This takes practice, but with some practice you can do it with any project, any task and any time.

This isn't 100% fool proof, but it does give you the best chances.
At the end of the pentathlon I had over 80k tasks that needed validated. I stopped crunching Universe@home 2 hours before the pentathlon ended. I still have over 17k tasks at the time of this post waiting to validate.

 

[thorsam]

@skelletor
Nach meiner Liste werden wir am 09.07.2022 beim Grillen 13 Leute sein.
Da 13 nicht unsere Glückszahl ist, mußt Du leider kommen.

P3D-Frühlingsgrillen in Dresden Mai 2024

Hallo Leute, Das P3D-Grillerchen findet am 4.5.2024 ab ~18 Uhr an der Feuerstelle Drachenschänke nahe dem Diakonissenkrankenhaus statt. Das Feuer markiert den Punkt: Sieht etwa so aus: FÜr die ÖPNV-Benutzer: Mit der 6 oder der 13 zum Rosa-Luxemburg-Platz oder zur Bautzner/Ecke Rothenburger...

forum.planet3dnow.de

 

[pipin]

Also irgendwas hakt hier immer noch extrem.

Das Projekt laesst sich bei mir immer noch nicht über den Boincmanager hinzufügen.
Wenn man eine Config-Datei erstellt, läuft man immer wieder in "Kommunikation verzögert" mit einem Offset von 24 Stunden hinein.

 

[JagDoc]

Also irgendwas hakt hier immer noch extrem.

Das Projekt laesst sich bei mir immer noch nicht über den Boincmanager hinzufügen.
Wenn man eine Config-Datei erstellt, läuft man immer wieder in "Kommunikation verzögert" mit einem Offset von 24 Stunden hinein.

Ich hab gerade probiert, in einer neuen Instanz Universe hinzugefügt, klappt ohne Problem.
Ist evtl. noch ein hosteintrag drin?

 

[pipin]

Ich hab gerade probiert, in einer neuen Instanz Universe hinzugefügt, klappt ohne Problem.
Ist evtl. noch ein hosteintrag drin?

Nein, das hab ich auch kontrolliert.

Hab auch den Tipp mit dem Löschen der config ausprobiert.
Seitdem dauerte der Timeout bis zur Meldung "Hinzufügendes Projektes fehlgeschlagen" anfangs etwas länger.
Kommt aber mittlerweile auch sofort wieder.

Andere Projekte kann man hinzufügen. Yoyo@home geht aber auch nicht.