Cafe climaprediction.net (News, Begrüßungen, SmallTalk zum Projekt & ...)

[HJL]

win wus. n paar (700). jetzt!

gegen 20.00 Uhr gabs allerdings keine mehr .., (höchstens noch paar Nachzügler oder abgebrochene)
hab mir mal einige sichern können, die scheinen diesmal sehr lange Laufzeiten zu haben, selbst auf relativ
schnellen Rechner ~ 120h, mit HT und so 200+

[Urs]

win wus!

HJL "FASS"

[HJL]

win wus!

HJL "FASS"

ich habe z.Z. andere Intensionen, hab aber mir aber trotzdem schon wieder welche eingefangen (64) ....
die haben allerdings keine Priorität 😉

[stevenluet]

Moin.

Irgendwie mag mich CPDN nicht mehr.

[lugu]

Ich hab gerade tatsächlich ganze 7 WAH2-WUs gekriegt!

[Urs]

Hab auch eine. Eine re. Lz 9T19St.

[xii5ku_AT]

Seit gestern Abend wird eine Serie von OpenIFS-Arbeitseinheiten herausgegeben, von der sich das Projekt erhofft, bis Weihnachten etwa 60,000 Resultate zurückzubekommen:
https://www.cpdn.org/forum_thread.ph...9&postid=66479

Umgekehrt heißt das also, das in den nächsten Wochen Stück für Stück wahrscheinlich 60,000 OpenIFS-Aufgaben ausgegeben werden, plus Resends.

• Die Anwendung läuft auf Linux x86-64.
• Auf typischen Desktop-CPUs dauert eine Aufgabe in der Größenordnung von 15 Stunden.
• Die maximale RAM-Anforderung während der Laufzeit einer Aufgabe könnte 8 GB betragen; typisch sind 3.2…4.2 GB RAM-Belegung.
• Während der Laufzeit produziert eine Aufgabe kontinuierlich Ergebnisdateien und lädt diese hoch. Es sind zusammen 123 Dateien zu je >14 MB Größe, insgesamt 1.72 GB hochzuladende Dateien pro Aufgabe.
• Bei 15 Stunden Laufzeit einer Aufgabe wäre somit 33.3 kByte/s Upload-Bandbreite pro aktiver CPU erforderlich, wenn man dort längere Zeit mitrechnen möchte.

[ID4]

Ich würde gerne mitmachen, aber da ich "linux frei" bin wird das wohl nichts.

Das es bei dem Projekt dauernd Arbeit für linux gibt und kaum was für Windows verteilt wird nervt mich ganz gewaltig.

[xii5ku_AT]

Bei CPDN plant man, die neue OpenIFS-Anwendung zunächst multicore-fähig zu machen, und anschließend eine VirtualBox-basierte Anwendungsversion für Windows auf die Beine zu stellen:
https://www.cpdn.org/forum_thread.ph...2&postid=66163
(D.h. dann wohl eine vboxwrapper-basierte Anwendung.) Wird aber noch eine Weile dauern, bis das passiert.

[KidDoesCrunch]

vbox? Vergiss es. Entweder nativ Windows oder null Punkte.

[xii5ku_AT]

Stelle ich mir auch unrealistisch vor. Nachdem dann auch noch vage Gedanken über eine Linux-vbox-Anwendung gepostet wurden (#66653), habe ich mich vorsorglich in dieser Hinsicht im Projektforum geäußert (#66672, #66685). Bei meinem Spruch bezüglich einer Minderheit von vbox-Befürwortern dachte ich an die spezielle Klientel, die mit dem Nullargument "hat für mich schon jahrelang prima funktioniert" um die Ecke kommt. Und siehe da: #66688. :-(

[ID4]

Ich bin auch nicht wirklich ein Freund von vbox, aber das funktioniert für mich eher als gar keine WU, weil fast alles nur Linux ist.

Vbox macht, zumindest für mich, weniger Ärger als ein "richtiges" Linux mit Boinc Client auf einem Computer oder einer VM aufzusetzen.


Ich habe die letzten Tage mit Linux in einer VM herum probiert.

Offensichtlich sind die Entwickler von Linux nicht in der Lage Linux auf die Benutzerfreundlichkeit von MacOs oder Windows zu bringen.

Das Aufsetzen eines Ubuntu 22.04 LTS oder Mint 21 Cinnamon in der VM war noch einfach.... Aber bei der Installation des Boinc Clients hakte es schon.

So Eigenheiten das ich ständig mein Passwort eingeben muß, oder das man Programme mit dieser Paketverwaltung sucht und installiert kann ich ja noch akzeptieren, aber dann muß das dann auch funktionieren.

In der Paketverwaltung Boinc suchen und installieren klicken und danach kann man das Programm starten kann man vergessen! Hat alles nicht hingehauen.

Die Idee auf dem alten iMac und dem MacBook Pro für die es keine Betriebssystemupdates mehr gibt Linux zu installieren habe ich nach der Erfahrung auch wieder verworfen.
Lieber betreibe ich die Geräte ohne MacOs Updates, als mich mit der beschissenen Benutzerführung von Linux herum zu quälen.

Damit ist bei mir das Thema Linux erst mal für die nächsten Jahre wieder vom Tisch!

[Stiwi]

Ich bin auch nicht wirklich ein Freund von vbox, aber das funktioniert für mich eher als gar keine WU, weil fast alles nur Linux ist.

Vbox macht, zumindest für mich, weniger Ärger als ein "richtiges" Linux mit Boinc Client auf einem Computer oder einer VM aufzusetzen.


Ich habe die letzten Tage mit Linux in einer VM herum probiert.

Offensichtlich sind die Entwickler von Linux nicht in der Lage Linux auf die Benutzerfreundlichkeit von MacOs oder Windows zu bringen.

Das Aufsetzen eines Ubuntu 22.04 LTS oder Mint 21 Cinnamon in der VM war noch einfach.... Aber bei der Installation des Boinc Clients hakte es schon.

So Eigenheiten das ich ständig mein Passwort eingeben muß, oder das man Programme mit dieser Paketverwaltung sucht und installiert kann ich ja noch akzeptieren, aber dann muß das dann auch funktionieren.

In der Paketverwaltung Boinc suchen und installieren klicken und danach kann man das Programm starten kann man vergessen! Hat alles nicht hingehauen.

Die Idee auf dem alten iMac und dem MacBook Pro für die es keine Betriebssystemupdates mehr gibt Linux zu installieren habe ich nach der Erfahrung auch wieder verworfen.
Lieber betreibe ich die Geräte ohne MacOs Updates, als mich mit der beschissenen Benutzerführung von Linux herum zu quälen.

Damit ist bei mir das Thema Linux erst mal für die nächsten Jahre wieder vom Tisch!

Mh...also ich hatte da bisher nie Probleme. früher maximal das die Grafikkarte nicht erkannt wurde aber ansonsten wars eigentlich einfach installieren und starten. Was gab es denn für einen Fehler?
Bin jetzt auch kein Linux Experte aber würde mich wundern wenn wir das nicht einfach zum laufen kriegen würden, falls überhaupt noch gewünscht
Kann natürlich verstehen wenn du keine Lust mehr hast auf Linux, es ist schon manchmal etwas unhandlich und es gibt oft nicht so tolle Gui-Tools wie unter windows wenn man bspw. den Stromverbrauch der Grafikkarte oder sowas anpassen will.

Ich persönlich rechne keine Projekte mehr die nur eine vbox Anwendung anbieten da das nur Probleme macht. Selber eine vBox aufsetzen und darin dann die natvie App rechnen läuft bei mir zumindest deutlich besser. Wobei ich auch Linux im Dualboot habe.

Edit: Außerdem sollte man wissen dass manche Projekte unter Linux deutlich schneller laufen (selbst in einer vBox) sodass es eine massive Stromverschwendung ist diese unter Windows zu rechnen

[xii5ku_AT]

Lieber betreibe ich die Geräte ohne MacOs Updates, als mich mit der beschissenen Benutzerführung von Linux herum zu quälen.

Sie kann subjektiv beschissen sein, objektiv ist sie lediglich anders, im Sinne von nicht komplett identisch.
Wenn man es gewohnt ist, kann man mit ganz wenigen Zeilen copy&paste eine frische virtuelle Maschine mit Linux und boinc-client aufsetzen und legt in weniger als einer Minute mit Distributed Computing los.

Ich habe früher nebenher ein bisschen Mac OS 7…10.4 benutzt. Dort bin ich nun so außer Übung, dass die primitivsten Anfängerschritte für mich (als jemand, der gegenüber variierenden Benutzerführungen auch eher wenig Geduld aufbringt) eine Qual sind.

[xii5ku_AT]

Seit gestern Abend wird eine Serie von OpenIFS-Arbeitseinheiten herausgegeben, von der sich das Projekt erhofft, bis Weihnachten etwa 60,000 Resultate zurückzubekommen:
https://www.cpdn.org/forum_thread.ph...9&postid=66479

Umgekehrt heißt das also, das in den nächsten Wochen Stück für Stück wahrscheinlich 60,000 OpenIFS-Aufgaben ausgegeben werden, plus Resends.

• Die Anwendung läuft auf Linux x86-64.
• Auf typischen Desktop-CPUs dauert eine Aufgabe in der Größenordnung von 15 Stunden.
• Die maximale RAM-Anforderung während der Laufzeit einer Aufgabe könnte 8 GB betragen; typisch sind 3.2…4.2 GB RAM-Belegung.
• Während der Laufzeit produziert eine Aufgabe kontinuierlich Ergebnisdateien und lädt diese hoch. Es sind zusammen 123 Dateien zu je >14 MB Größe, insgesamt 1.72 GB hochzuladende Dateien pro Aufgabe.
• Bei 15 Stunden Laufzeit einer Aufgabe wäre somit 33.3 kByte/s Upload-Bandbreite pro aktiver CPU erforderlich, wenn man dort längere Zeit mitrechnen möchte.

Seit Dienstag Abend ist nun tatsächlich für kontinuierliche Versorgung mit Arbeit für "OpenIFS 43r3 Perturbed Surface v1.05 x86_64-pc-linux-gnu" gesorgt. Updates:
– Es sind 39 000 Arbeitseinheiten vorgesehen.
– Diese werden jetzt zwar nicht alle auf einmal, aber womöglich doch ohne die sonst typischen "0 tasks ready to send"-Lücken auf den Server gegeben.
– Typische Laufzeit pro Aufgabe bleibt wie oben genannt.
– Die Rate, mit der Ergebnisdaten produziert werden, bleibt genau wie oben beschrieben. Deshalb wurde als Upload-Server ein größer als bisher dimensionierter Cloud-Server in Dienst gestellt.
– Der maximale RAM-Bedarf einer laufenden Aufgabe tritt immer nur in kurzen Spitzen auf (wenn der Strahlungs-Code läuft, der mit größeren Zeitschritten als andere Code-Teile abgearbeitet wird).
– Diese kurzzeitigen Spitzen in der RAM-Belegung dürften es dem Boinc-Client erschweren, selbständig die Anzahl gleichzeitig laufender OpenIFS-Aufgaben im Zaum zu halten. Nach meiner Beobachtung liegt der Spitzenbedarf wohl bei 4,8 MB, könnte wie oben bemerkt aber je nach Arbeitseinheit auch noch mehr werden. Der Server gibt 5.6 GB als rsc_memory_bound in den Arbeitseinheiten an.
– Ferner gibt der Server 7.0 GB Festplattenplatz pro Arbeitseinheit an.

Sowohl wegen der Upload-Rate als auch wegen des RAM-Bedarfs und ggf. des Massenspeicherbedarfs sollte der Anwender dafür sorgen, dass nicht zu viele OpenIFS-Aufgaben zugleich laufen.

[Felix_M_]

Vielen Dank für deine Zusammenfassung, fasst die Hunderten Foreneinträge schön zusammen
Eine Korrektur:

– Diese kurzzeitigen Spitzen in der RAM-Belegung dürften es dem Boinc-Client erschweren, selbständig die Anzahl gleichzeitig laufender OpenIFS-Aufgaben im Zaum zu halten. Nach meiner Beobachtung liegt der Spitzenbedarf wohl bei 4,8 GB, könnte wie oben bemerkt aber je nach Arbeitseinheit auch noch mehr werden. Der Server gibt 5.6 GB als rsc_memory_bound in den Arbeitseinheiten an.

Da hast glaub ich die falsche Größeneinheit erwischt

Grüße
Felix

[xii5ku_AT]

Ups. Von Mitte zu Mitte gemessen liegen M und G auf meiner Tastatur 51 mm auseinander; an dicken Fingern kann es somit nicht gelegen haben.

[Felix_M_]

Passiert

[xii5ku_AT]

Man sollte außerdem das Boinc-Verzeichnis auf einem mindestens normal schreibfesten Datenträger liegen haben, also z.B. gewöhnliche HDD oder SSD, jedoch lieber nicht auf USB-Stick oder SD-Card. Denn pro laufender OpenIFS-Aufgabe der derzeitigen Batches gibt es um die 1…3 MB/s Schreibvolumen (zeitgemittelt, je nach Ausführungsgeschwindigkeit — und diesmal tatsächlich M, nicht G).

[taurec]

hm, ich habe hier jetzt zwei von den Wus fertig, stehen unter gütlig mit Null Punkten:

[Felix_M_]

Würde ich mir zunächst keine Sorgen machen. Bei CPDN läuft das Creditscript nur ein mal in der Woche, ich meine Sonntags um die Mittagszeit etwa.

[joe_carnivore]

[*] Während der Laufzeit produziert eine Aufgabe kontinuierlich Ergebnisdateien und lädt diese hoch. Es sind zusammen 123 Dateien zu je >14 MB Größe, insgesamt 1.72 GB hochzuladende Dateien pro Aufgabe.
[/list]

Bei mir waren schon welche mit 24 oder 27 MB pro trickle.

[ID4]

Man sollte außerdem das Boinc-Verzeichnis auf einem mindestens normal schreibfesten Datenträger liegen haben, also z.B. gewöhnliche HDD oder SSD, jedoch lieber nicht auf USB-Stick oder SD-Card. Denn pro laufender OpenIFS-Aufgabe der derzeitigen Batches gibt es um die 1…3 MB/s Schreibvolumen (zeitgemittelt, je nach Ausführungsgeschwindigkeit — und diesmal tatsächlich M, nicht G).

Kein Problem. Ich habe noch >200 Micron C400 128gb SSDs......

Das dauert ein Weilchen bis ich die tot geschrieben habe.

[xii5ku_AT]

Während der Laufzeit produziert eine Aufgabe kontinuierlich Ergebnisdateien und lädt diese hoch. Es sind zusammen 123 Dateien zu je >14 MB Größe, insgesamt 1.72 GB hochzuladende Dateien pro Aufgabe.

Bei mir waren schon welche mit 24 oder 27 MB pro trickle.

Das ist die letzte Datei mit der Nummer 122 (von 0…122). In die wird noch ein bisschen Überschuss hineingepackt, so dass sie größer ist als die vorangegangenen Dateien.

Kann man z.B. jetzt sehr gut sehen, da der Upload-Server seit gestern Abend außer Funktion ist, und sich nun im Boinc-Client zahlreiche auf den Upload wartende Ergebnisdateien aufgestaut haben dürften.

Ob der Upload-Server schon nach Weihnachten oder erst im neuen Jahr wieder zum Laufen gebracht wird, bleibt nun abzuwarten…

[joe_carnivore]

Leider sind bei mir von der einen WU nur noch 121 und 122 im upload. Die sind 27 und 43 MB groß.
Ich bin der Meinung das es immer 27 MB waren . Ich hatte mir gestern mal die Größen notiert.

Sonst sind ja alle 14 MB.