SiDock@home: SiDock@home September Sailing
Re: SiDock@home: SiDock@home September Sailing
Von den Pendings werden sicher noch einige aufgelöst wenn die Bunker hochgeladen werden.
Das die Pendings immer weiter ansteigen liegt aber auch an der Unfähigkeit von Boinc ( weiß nicht ob es ein Boinc oder Betreiberproblem ist) dem Boincclient einen Laufzeitsprung der WU's mitzuteilen.
Damit werden dann Rechner überladen, vor allem die Systeme die eh schon lahm sind kriegen die WU's nicht in 2-3 Tagen fertig.
Selbst die 3900X haben für die 6h WU's noch eine Schätzzeit von 3h33 min drin stehen, die rechnen aber schon seit erscheinen der WU's dran. Der 9h 5820k ist noch bei 1h20min.
Dieses Projekt ist für mich vor allem durch das wirklich mies laufende Creditsystem völlig unten durch, die Serverperformance war gar nicht so schlimm.
Der wurde doch u.a. durch die Bunker unter Druck gesetzt.
Bei Projekten bei denen man gut Bunkern kann versuche ich mich mit unseren anderen Teammitgliedern abzusprechen damit nicht zur gleichen Zeit extrem viele WU's hochgeladen werden.
Da hilft auch sehr gut die Anzeige in Grafana. Das scheint bei manch anderen Teams nicht so gut zu klappen oder es sind ein paar wenige Cruncher mit richtig dicker (DSL) Leitung dabei die viele Rechner gleichzeitig hochladen.
Richtig mies wurde der Server erst mit der großen Anzahl an WU's die im Validator hingen.
Von Betreiberseite aus war es sehr ungeschickt als erstes die kurzen WU's rechnen zu lassen, deren Laufzeit ist im Verhältnis von WU-Downloadgrösse und Uploadgrösse nicht für ein Race geeignet. Bei der Rechenzeit liegt der Faktor 12 dazwischen und bei der Dateigrösse sind es wohl immer noch Faktor 6, da habe ich aber wegen funktionieredem Server nicht genug WU's gesehen.
Um bei dem Bild von Michael H.W. Weber zu bleiben waren die kurzen WU's der 5 Kilo Hammer der auch noch mehr als 10 Mal so häufig zugeschlagen hat.
Oder anders ausgedrückt, wenn ich mit den langen WU's mit 1Gbit hinkommen würde bräuchte ich bei den kurzen WU's schon 10Gbit. Bei 10GBit öffnet sich aber der nächste Flaschenhals Plattensystem.
Auf der Clientseite haben wir seit Einführung der ersten Ryzen-CPU's eine Verdopplung, mit dem 12 Kerner Zen 2 wieder eine Verdopplung und damit ligen wir mit dem aktuellen 16 Kerner wohl mindestens beim Faktor 5 was den Lastanstieg angeht.
Und das innerhalb von 4,5 jahren. Die I/O Seite ist aber nicht wirklich mitgekommen.
Das die Pendings immer weiter ansteigen liegt aber auch an der Unfähigkeit von Boinc ( weiß nicht ob es ein Boinc oder Betreiberproblem ist) dem Boincclient einen Laufzeitsprung der WU's mitzuteilen.
Damit werden dann Rechner überladen, vor allem die Systeme die eh schon lahm sind kriegen die WU's nicht in 2-3 Tagen fertig.
Selbst die 3900X haben für die 6h WU's noch eine Schätzzeit von 3h33 min drin stehen, die rechnen aber schon seit erscheinen der WU's dran. Der 9h 5820k ist noch bei 1h20min.
Dieses Projekt ist für mich vor allem durch das wirklich mies laufende Creditsystem völlig unten durch, die Serverperformance war gar nicht so schlimm.
Der wurde doch u.a. durch die Bunker unter Druck gesetzt.
Bei Projekten bei denen man gut Bunkern kann versuche ich mich mit unseren anderen Teammitgliedern abzusprechen damit nicht zur gleichen Zeit extrem viele WU's hochgeladen werden.
Da hilft auch sehr gut die Anzeige in Grafana. Das scheint bei manch anderen Teams nicht so gut zu klappen oder es sind ein paar wenige Cruncher mit richtig dicker (DSL) Leitung dabei die viele Rechner gleichzeitig hochladen.
Richtig mies wurde der Server erst mit der großen Anzahl an WU's die im Validator hingen.
Von Betreiberseite aus war es sehr ungeschickt als erstes die kurzen WU's rechnen zu lassen, deren Laufzeit ist im Verhältnis von WU-Downloadgrösse und Uploadgrösse nicht für ein Race geeignet. Bei der Rechenzeit liegt der Faktor 12 dazwischen und bei der Dateigrösse sind es wohl immer noch Faktor 6, da habe ich aber wegen funktionieredem Server nicht genug WU's gesehen.
Um bei dem Bild von Michael H.W. Weber zu bleiben waren die kurzen WU's der 5 Kilo Hammer der auch noch mehr als 10 Mal so häufig zugeschlagen hat.
Oder anders ausgedrückt, wenn ich mit den langen WU's mit 1Gbit hinkommen würde bräuchte ich bei den kurzen WU's schon 10Gbit. Bei 10GBit öffnet sich aber der nächste Flaschenhals Plattensystem.
Auf der Clientseite haben wir seit Einführung der ersten Ryzen-CPU's eine Verdopplung, mit dem 12 Kerner Zen 2 wieder eine Verdopplung und damit ligen wir mit dem aktuellen 16 Kerner wohl mindestens beim Faktor 5 was den Lastanstieg angeht.
Und das innerhalb von 4,5 jahren. Die I/O Seite ist aber nicht wirklich mitgekommen.
- joe carnivore
- Task-Killer
- Beiträge: 745
- Registriert: 04.05.2013 06:01
- Wohnort: Goslar, NI / Lower Saxony ,Germany
Re: SiDock@home: SiDock@home September Sailing
Wenn man an den ncpus nicht rumspielt kann das nicht passieren , bei Kernanzahl x 2 = WU Menge.csbyseti hat geschrieben: ↑18.09.2021 09:59
Das die Pendings immer weiter ansteigen liegt aber auch an der Unfähigkeit von Boinc ( weiß nicht ob es ein Boinc oder Betreiberproblem ist) dem Boincclient einen Laufzeitsprung der WU's mitzuteilen.
Damit werden dann Rechner überladen, vor allem die Systeme die eh schon lahm sind kriegen die WU's nicht in 2-3 Tagen fertig.
Bei der Credit vergabe bin ich bei Dir. Das dort noch kein shitstorm gekommen ist.
Re: SiDock@home: SiDock@home September Sailing
Nö, das ist unabhängig davon ob man an den ncpus rumspielt oder nicht. Letzteres schärft die Situation nur noch mehr wenn man das übertreibt.joe carnivore hat geschrieben: ↑18.09.2021 11:36Wenn man an den ncpus nicht rumspielt kann das nicht passieren , bei Kernanzahl x 2 = WU Menge.csbyseti hat geschrieben: ↑18.09.2021 09:59
Das die Pendings immer weiter ansteigen liegt aber auch an der Unfähigkeit von Boinc ( weiß nicht ob es ein Boinc oder Betreiberproblem ist) dem Boincclient einen Laufzeitsprung der WU's mitzuteilen.
Damit werden dann Rechner überladen, vor allem die Systeme die eh schon lahm sind kriegen die WU's nicht in 2-3 Tagen fertig.
Bei der Credit vergabe bin ich bei Dir. Das dort noch kein shitstorm gekommen ist.
Wobei das rumspielen an ncpus ja vor allem dann passiert wenn ein Projekt absichtlich limitiert ist und sich nicht normal verhält.
Wenn ein Projekt sich normal verhält und man sich für 3 Tage WU's gezogen hat hat man eine bestimmte Anzahl WU's die auch innerhalb der Deadline zurückkommen.
Kommt nun aber ein Sprung in der Laufzeit um den Faktor 12 ohne das das dem Boincclient mitgeteilt wird hat man plötzlich WU's für 36 Tage statt für 3 Tage.
Was das schon im Normalbetrieb bedeutet kann man sich ausmalen, in einem Race kann das zu ganz erheblichen Verwerfungen führen.
Und für die Serverdatenbank ist das auch nicht hilfreich.
Bei meinen 3900X war das trotz ncpus auch kein Problem, der hatte ja nur max 365 WU's. Das hat ja nicht mal einen halben Tag gereicht.
Die werden die WU's auch alle wegrechnen können.
Bei den älteren CPU's sieht das schon anders aus weil die ~ die gleiche Anzahl WU's gezogen hatten. Nachdem ich das bemerkt habe habe ich dort erst mal das nachziehen von WU's über den Puffer beschränkt.
Der gleiche Effekt tritt aber auch auf wenn man ohne ncpus und nur mit Instanzen fährt um möglichst abgehangene WU's zu haben. Wenn man nicht von vornherein die passende Anzahl WU's in den Instanzen haben will sondern sagt bei der Deadline und der Racelaufzeit reicht es auch wenn man in der Racemitte noch mal nachzieht. Dann zieht man halt WU's mit einem um den Faktor 12 längeren Laufzeit.
Wenn ich yoyo richtig verstanden habe müsste eigentlich der Server der WU die geänderten geschätzten Flops mitgeben. Das wäre dann ein Versäumniss bei den Projektbetreibern.
Re: SiDock@home: SiDock@home September Sailing
Vor allem, wenn am Anfang die 25 min Wus kamen, anschließend 5 Stunden WUs, um dann wieder 15- -20 Min WUs hinterher zu liefern, denen jetzt wieder 5 Std WUs folgten, also ein ständiges Hin und Her der Rechenzeiten pro WU.csbysety hat geschrieben:Was das schon im Normalbetrieb bedeutet kann man sich ausmalen, in einem Race kann das zu ganz erheblichen Verwerfungen führen.
Wenn man mit "ncpu" herumgedoktert hat, um wenigstens für wenige Stunden Material zum Rechnen zu haben, kann man im Grunde genommen nur die überzähligen Wus zurückgeben, wenn wieder die 5 Stunden WUs gesendet werden, damit nicht alles bei Herrn Pen Ding landet.
Gruß Harald
Meine Kommentare sind grundsätzlich nicht Chauvinistischer, Misogynischer, Xenophobischer, Homophobischer oder Religionfeindlicher Natur, sondern dienen lediglich der Konversation und repräsentieren ansonsten die schlichte, rheinische Denkungsweise.
s
Meine Kommentare sind grundsätzlich nicht Chauvinistischer, Misogynischer, Xenophobischer, Homophobischer oder Religionfeindlicher Natur, sondern dienen lediglich der Konversation und repräsentieren ansonsten die schlichte, rheinische Denkungsweise.
s
Re: SiDock@home: SiDock@home September Sailing
Ich habe mal was zu dem Credit-System bei Sidock geschrieben, ich denke meine Punkte stimmen so weit.
https://www.sidock.si/sidock/forum_thre ... =1204#1204
https://www.sidock.si/sidock/forum_thre ... =1204#1204
Re: SiDock@home: SiDock@home September Sailing
Das ist glaube ich nicht deren Creditsystem sondern halt einfach der Linux/Ubuntu Bug der bei vielen Projekten mit den Credits ausgenutzt wird bspw. bei Yoyo.
Vergleich mal die Boinc Werte für die ermittelten Geschwindigkeiten unter windows und Linux du wirst sehen dass Linux deutlich höhere Werte ermittelt. Ich glaube das ist das standart Boinc Credit system was sich dann folgerichtig verhält für das System hast du dann mehr Arbeit geleistet da du genauso lange gebraucht hast. Einige Projekte sind deswegen auch auf feste Credits pro WU gegangen.
Aber vielleicht habe ich dein Problem auch missverstanden.
Edit: Ich glaube es kommt dann auch drauf an wer die WU validiert. Ein Windows Wingman (oder Linux mit gefixten Benchmark?) zieht die Credits runter
Vergleich mal die Boinc Werte für die ermittelten Geschwindigkeiten unter windows und Linux du wirst sehen dass Linux deutlich höhere Werte ermittelt. Ich glaube das ist das standart Boinc Credit system was sich dann folgerichtig verhält für das System hast du dann mehr Arbeit geleistet da du genauso lange gebraucht hast. Einige Projekte sind deswegen auch auf feste Credits pro WU gegangen.
Aber vielleicht habe ich dein Problem auch missverstanden.
Edit: Ich glaube es kommt dann auch drauf an wer die WU validiert. Ein Windows Wingman (oder Linux mit gefixten Benchmark?) zieht die Credits runter
Re: SiDock@home: SiDock@home September Sailing
Bin ein wenig erschrocken, als ich das posting bei SiDock eben las. Die Ausdrucksweise ist ein wenig problematisch, wenn man jemanden sucht, der/die sich seines Problems annehmen möchte. Ein "problematic" statt "bullshit" und die eMail wäre ok.csbyseti hat geschrieben: ↑18.09.2021 17:14Ich habe mal was zu dem Credit-System bei Sidock geschrieben, ich denke meine Punkte stimmen so weit.
https://www.sidock.si/sidock/forum_thre ... =1204#1204
Meine Vermutung ist, dass man nicht so supergut abschätzen kann, wie lang eine Rechnung dauert, hängt vermutlich von den jeweiligen zu testenden Liganden ab. Klar, man kann sich nun hinsetzen, sich die Liganden jeweils auf deren Größe und Flexibilität hin abchecken, aber man kann es auch sein lassen und sich auf andere Sachen konzentrieren. Optimierungen beispielsweise. Oder das Schreiben eines Forchungsantrags. Das Bunkern für irgendeine Medallie ist nicht wirklich eines Wissenschaftlers Herzensangelegenheit. Im Interesse des Projektes wäre es, die bessere Platzierung durch dem Projekt hinzugefügte Rechner uierreichen.
Wen haben wir den unter uns, der eine Laufzeitabschätzung hinbekommt und dafür Zeit und Laune hätte, dies zu implementieren?
Re: SiDock@home: SiDock@home September Sailing
Ja, über die Wortwahl kann man streiten. Aber man kann schon erwarten, dass die Berechnungen halbwegs sauber und ohne große Komplikationen laufen können. Die Cruncher-Szene hat ja nicht nach einem einwöchigen Race gerufen, das hat SiDock von sich aus initiiert und dazu noch schöne Bildchen als Belohnung entworfen. Es ist ein Geben und Nehmen: Wir bekommen tolle Abzeichen und die Möglichkeit, uns im Wettbewerb mit anderen zu messen, SiDock bekommt unsere Rechenpower, die ja im Übrigen eine geldwerte Spende darstellt. Und dafür darf man schon verlangen, dass es einigermaßen läuft. Noch dazu, wenn die Projektbetreiber im Mai im Pentathlon schon Erfahrungen mit einer längeren Race gesammelt haben.smoe hat geschrieben: ↑18.09.2021 19:47Klar, man kann sich nun hinsetzen, sich die Liganden jeweils auf deren Größe und Flexibilität hin abchecken, aber man kann es auch sein lassen und sich auf andere Sachen konzentrieren. Optimierungen beispielsweise. Oder das Schreiben eines Forchungsantrags. Das Bunkern für irgendeine Medallie ist nicht wirklich eines Wissenschaftlers Herzensangelegenheit. Im Interesse des Projektes wäre es, die bessere Platzierung durch dem Projekt hinzugefügte Rechner uierreichen.
Ryzen 7 3700X ~ GeForce GTX 1660 ~ 32GB RAM ~ Ubuntu 20.04
- Michael H.W. Weber
- Vereinsvorstand
- Beiträge: 22431
- Registriert: 07.01.2002 01:00
- Wohnort: Marpurk
- Kontaktdaten:
Re: SiDock@home: SiDock@home September Sailing
Ja, das war so nicht nötig.
Ich kann einerseits nachvollziehen, dass man auch mal sauer ist, aber meist kommt man weiter, wenn man freundlich konkrete Verbesserungsvorschläge macht.
Michael.
Fördern, kooperieren und konstruieren statt fordern, konkurrieren und konsumieren.
http://signature.statseb.fr I: Kaputte Seite A
http://signature.statseb.fr II: Kaputte Seite B
http://signature.statseb.fr I: Kaputte Seite A
http://signature.statseb.fr II: Kaputte Seite B
Re: SiDock@home: SiDock@home September Sailing
Das die Ausdrucksweise suboptimal war ist sicher richtig, dafür drückt es meine Meinung darüber aus.
Zu dem Punkt es liegt an Linux, das stimmt nicht. Es sind beide 3900X betroffen. Sowohl der Windows als auch der Linux.
Wenn man sich nicht die Zeit nehmen will bestimmte Punkte zu bearbeiten kann man fixed Credits für einen Workset nehmen zumal innerhalb eines Workset die Laufzeitspreizung nicht groß ist.
Das gäbe dann wenigstens eine faire Punkteverteilung.
Zweitens könnte man den Unfug mit den Arm CPU's lassen, dann spart man viel Zeit und ändert am WU-Durchsatz praktisch gar nichts.
Dann müsste man sich auch nicht über Wingman ärgern die 1,5 Tage dafür brauchen in einen Berechnungsfehler zu laufen.
https://www.sidock.si/sidock/results.php?hostid=21103
Dann kommt noch dazu das von den langen WU's jetzt extrem viele abgebrochen werden weil es ja aus Race-Sicht überhaupt keinen Sinn macht diese zu rechnen.
https://www.sidock.si/sidock/workunit.php?wuid=11108942
Sowas nützt ja dem Projekt gar nicht.
Aber das kommt dann dabei raus wenn man sich gar nicht um das einzige kümmert was man an die vielen Unterstützer zurückgeben kann.
Ich bin nicht der Meinung das Boinc eine Einbahnstrasse ist bei der ein Projektbetreiber sich um nichts kümmern muss.
Zu dem Punkt es liegt an Linux, das stimmt nicht. Es sind beide 3900X betroffen. Sowohl der Windows als auch der Linux.
Wenn man sich nicht die Zeit nehmen will bestimmte Punkte zu bearbeiten kann man fixed Credits für einen Workset nehmen zumal innerhalb eines Workset die Laufzeitspreizung nicht groß ist.
Das gäbe dann wenigstens eine faire Punkteverteilung.
Zweitens könnte man den Unfug mit den Arm CPU's lassen, dann spart man viel Zeit und ändert am WU-Durchsatz praktisch gar nichts.
Dann müsste man sich auch nicht über Wingman ärgern die 1,5 Tage dafür brauchen in einen Berechnungsfehler zu laufen.
https://www.sidock.si/sidock/results.php?hostid=21103
Dann kommt noch dazu das von den langen WU's jetzt extrem viele abgebrochen werden weil es ja aus Race-Sicht überhaupt keinen Sinn macht diese zu rechnen.
https://www.sidock.si/sidock/workunit.php?wuid=11108942
Sowas nützt ja dem Projekt gar nicht.
Aber das kommt dann dabei raus wenn man sich gar nicht um das einzige kümmert was man an die vielen Unterstützer zurückgeben kann.
Ich bin nicht der Meinung das Boinc eine Einbahnstrasse ist bei der ein Projektbetreiber sich um nichts kümmern muss.
- Michael H.W. Weber
- Vereinsvorstand
- Beiträge: 22431
- Registriert: 07.01.2002 01:00
- Wohnort: Marpurk
- Kontaktdaten:
Re: SiDock@home: SiDock@home September Sailing
Was genau ist Unfug an einem ARM-Client?csbyseti hat geschrieben: ↑19.09.2021 10:20Zweitens könnte man den Unfug mit den Arm CPU's lassen, dann spart man viel Zeit und ändert am WU-Durchsatz praktisch gar nichts.
Dann müsste man sich auch nicht über Wingman ärgern die 1,5 Tage dafür brauchen in einen Berechnungsfehler zu laufen.
https://www.sidock.si/sidock/results.php?hostid=21103
Michael.
Fördern, kooperieren und konstruieren statt fordern, konkurrieren und konsumieren.
http://signature.statseb.fr I: Kaputte Seite A
http://signature.statseb.fr II: Kaputte Seite B
http://signature.statseb.fr I: Kaputte Seite A
http://signature.statseb.fr II: Kaputte Seite B
Re: SiDock@home: SiDock@home September Sailing
Das frage ich mich auch.Michael H.W. Weber hat geschrieben: ↑19.09.2021 10:58Was genau ist Unfug an einem ARM-Client?csbyseti hat geschrieben: ↑19.09.2021 10:20Zweitens könnte man den Unfug mit den Arm CPU's lassen, dann spart man viel Zeit und ändert am WU-Durchsatz praktisch gar nichts.
Dann müsste man sich auch nicht über Wingman ärgern die 1,5 Tage dafür brauchen in einen Berechnungsfehler zu laufen.
https://www.sidock.si/sidock/results.php?hostid=21103
Michael.
Vor allem liegt es an falschen Einstellungen in den langen WUs das die Rechner in das Timelimit laufen.
Betrifft auch andere Rechner.
https://www.sidock.si/sidock/forum_thread.php?id=149