SiDock@home

[xii5ku_AT]

Hm, bei mir kommen keine WUs mehr an, obwohl der Server sagt, es gäbe noch welche...

Zum Einen ist ja server_status nicht immer top-aktuell.

Zum Anderen ist die Zahl "Tasks ready to send" nur eine Summe über alles. Wir wissen nicht, wie viele Aufgaben davon der Scheduler an "Hinz und Kunz" zu verteilen bereit ist, und wie viele nur an "verlässliche" Rechner abgegeben werden sollen. Das sind Rechner, die in jüngerer Zeit viele richtige Ergebnisse geliefert haben, und zwar innerhalb relativ kurzer Zeit nach Abholen der Arbeit.

Wenn z.B. eine Aufgabe vom User abgebrochen wird oder in einem Fehler endet oder die Deadline überschritten wurde, dann generiert der Server eine neue Aufgabe für dieselbe WU, sendet diese neue Aufgabe aber typischerweise nur an Rechner, die zur Zeit als "verlässlich" gelten. Die Kriterien können m.W. vom Projektadministrator festgelegt werden. Vermutlich gibt es voreingestellte Parameter, und diese oder die vom Admin gewählten können ungünstigenfalls mal zum Schluckauf im Projekt führen, wenn mal sehr viele solcher speziellen Aufgaben in die Warteschlange kommen.

Dies ist aber nur eine Ursache unter mehreren, warum ein konkreter Rechner mal keine Aufgabe bekommt, obwohl der Server insgesamt noch welche zu vergeben hätte. Ob dies gestern bei SiDock zum Tragen kam, weiß ich nicht.

[nexiagsi16v]

Mein Rechner hat mal zwischen 4 und 5 und dann noch mal zwischen 5 und 6 Uhr keine WUs gezogen. Aber er rechnet noch für andere Projekte, von daher war evtl. auch einfach mal kein Platz mehr da.

Mein i3 8300 mit Linux64bit liegt bei CurieMarieDock v1.00 zwischen 11-21 Minuten und bei RxDock v1.00 zwischen 13-32 Minuten. Mein 10 Jahre alter Intel b940 braucht ca. 3x so lange, aber wie gesagt, bei überschaubarer Systembelastung.

[taurec]

Habe bei mir TN-Grid und/oder Gaia als Backupprojekt eingestellt mit Prio Null, dann klappt das auch ohne Leerlaufen der Rechner

[marodeur6]

Danke für eure Antworten hier.

Es ist etwas unglücklich, wenn ein Projekt jeden morgen für mehrere Stunden keine WUs ausgibt und ein Limit an zu versendenden WUs pro Rechner hat...
Ich werde mal schauen, wie ich per Script öfter morgens aktualisiere, da ich ein paar Stunden mehr Leerlauf habe, als es sein müsste.

Update: Da meine Rechner unter Windows 10 laufen, habe ich es mit Z-Cron realisiert.

[AxelS]

Das Limit der WUs pro Rechner ist offensichtlich an der Anzahl der Cores multipliziert mit zwei festgelegt:
Meine beiden Linux-Hosts mit 16 Kerne pro CPU bekommen 32 WUs gleichzeitig zugeschickt. Ein anderer Linux-Rechner mit 12 Kerne bekommt nur 24 WUs.

Bei meinen Windows-Rechner mit 8 Cores sind es nur 16 WUs.

Es ist seltsam bei diesem Projekt. Immer mein Win-Rechner ist der erste, der zuerst leer läuft. Wobei die anderen Rechner meistens noch WUs bekommen haben. Das beobachte bereits mehrfach seit ca. mitte Dezember letzten Jahres.

[nexiagsi16v]

Liegt evtl. daran, das für CurieMarieDock 4.800 GigaFLOPS Rechenleistung bereitgestellt wird und für RxDock nur 2.200 GigaFLOPS. Also ein Verhältnis von 2,2:1. Das Verhälts der ungesendet WUs ist aber aktuell nur 1,4:1.
Und nun der Knackpunkt, RxDock gibt es nur für Linux/Mac. Also laufen die er später trocken, weil weniger Rechner dran sind. Bei CurieMarieDock bedienen sich Win/Linux/Mac gleichzeitig.

btw. sie nennen ihren Server "Natalia". Isch bin verliebt.

[taurec]

Ich habe mir bei meinem Ryzen2700x jetzt wie folgt beholfen:
1. app_config.xml: max_concurrent auf 14 gesetzt für SiDock, zwei Threads bleiben für die GPUs
2. cc_config.xml: ncpus auf 128
Nun habe ich 128 WUs vorrätig (es werden anscheinend nur 64 ncpus akzeptiert), sollte reichen für die nächsten 10 Stunden, also besser als vorher mit nur maximal zwei Stunden.
Wenn mehrere Projekte gerechnet werden, müssen natürlich die app_config.xml pro Projekt angepasst werden, so dass die maximale physikalische Kern-/Threadanzahl nicht überschritten wird.

[Felix_M_]

btw. sie nennen ihren Server "Natalia". Isch bin verliebt.

Natalia ist eine der Admins

[nexiagsi16v]

...ich könnte mein Russisch mal wieder aufbessern, fällt mir grade spontan ein.

[AxelS]

Und nun der Knackpunkt, RxDock gibt es nur für Linux/Mac. Also laufen die er später trocken, weil weniger Rechner dran sind. Bei CurieMarieDock bedienen sich Win/Linux/Mac gleichzeitig.

Das ist mit Sicherheit ein möglicher Punkt. CurieMarieDock werden durch die vielen Win-Rechner schneller weg-gecruncht. Eben weil auch die Linux-Rechner auch daran beteiligt sind. Es ist ja nicht so als ob auf den Linux Kisten nur noch RxDock vorhanden wären. Mein Win-Rechner holt einfach keine neuen WUs. Auch bei neu auf dem Projektserver eingestellte WUs werden von BOINC-Client unter Win nicht abgefragt. Erst das manuelle Anstoßen per Hand oder per Script sorgt für neuen Schwung bei der WU-Versorgung. *schulterzuck*

[xii5ku_AT]

Hier gibt es Grafiken des Zeitverlaufs von "Tasks ready to send" und "Tasks in progress":
https://munin.kiska.pw/munin/Munin-N...ts_sidock.html
Darin wird freilich nicht zwischen RxDock und CurieMarieDock unterschieden.

[nexiagsi16v]

Aktuell: Tasks ready to send 0

Evtl. liegt es auch daran, dass das aktuell Projekt fast durch ist? arget: corona_3CLpro_v3 (%) 99.587

[Felix_M_]

das ist noch der Status des letzten Targets.

Inzwischen sind wieder ausreichend Tasks verfügbar zum Download

[AxelS]

Nun haben wir ein neues Target mit neuen Aufgaben:

Status der Berechnung
Research progress
Target: corona_3CLpro_v3 (%) 0.021

[...]
Task data as of 7 Jan 2021, 18:26:38 UTC

[pschoefer]

Seit ich bei diesem Projekt aktiv bin (mit der CurieMarieDock-Anwendung, da Windows), habe ich auf dem Notebook, an dem ich hauptsächlich meine Zeit verbringe, öfter mit Bildrucklern zu kämpfen bis hin zum Aufhängen des Grafiktreibers. Zunächst fürchtete ich, dass ich die GPU Ende Dezember gegrillt hätte (normalerweise idlet sie, aber da hatte ich sie für die PG-Challenge freigegeben), aber die Probleme sind jeweils verschwunden, als ich SiDock@home letzte Woche einmal vor einem Reboot und letzte Nacht vor der jetzigen PG-Challenge auslaufen ließ. Die CPU ist zwar nicht mehr die allerneueste (i7-2670QM), aber eigentlich ist dieses Projekt ja deutlich friedlicher als etwa LLR, wo alles flüssig läuft. Hat jemand ähnliche Probleme?

[Felix_M_]

ich konnte auch schon feststellen, dass die CPU stark gefordert wird, auch wenn sie nicht so warm wird wie bei LLR. Scheinbar gibt es hier andere Faktoren, welche hier limitierend wirken.
Ich bekomme mit 10 wus auf 12 cores meinen I7 auch auf 98% auslastung. Rechnerisch wären 8,3% ein Core auf Volllast, 8,3-8,5% ist so das was ich hier sehe, was ein Task benötigt.

[xii5ku_AT]

Nun haben wir ein neues Target mit neuen Aufgaben:

Das ist nun auch schon wieder zu >80 % abgearbeitet. :-)

Seit ich bei diesem Projekt aktiv bin (mit der CurieMarieDock-Anwendung, da Windows), habe ich auf dem Notebook, an dem ich hauptsächlich meine Zeit verbringe, öfter mit Bildrucklern zu kämpfen bis hin zum Aufhängen des Grafiktreibers. Zunächst fürchtete ich, dass ich die GPU Ende Dezember gegrillt hätte (normalerweise idlet sie, aber da hatte ich sie für die PG-Challenge freigegeben), aber die Probleme sind jeweils verschwunden, als ich SiDock@home letzte Woche einmal vor einem Reboot und letzte Nacht vor der jetzigen PG-Challenge auslaufen ließ. Die CPU ist zwar nicht mehr die allerneueste (i7-2670QM), aber eigentlich ist dieses Projekt ja deutlich friedlicher als etwa LLR, wo alles flüssig läuft. Hat jemand ähnliche Probleme?

Bildruckler -> Vielleicht führen rxdock/cmdock viele Hauptspeicher-Zugriffe aus. Könnte man experimentell herausfinden, indem man mit Dualchannel-RAM und mit Singlechannel-RAM testet. (Wegen CreditNew wäre ein synthetischer Test mit fixer WU günstig.) Oder wer in software engineering zu Hause ist, könnte das womöglich mit einem profiler herausbekommen.

Aufhängen des Grafiktreibers -> Da bin ich ratlos.

[pschoefer]

Inzwischen sind fast alle WUs zum zweiten simulierten Bindungsziel (PLpro) berechnet, weshalb es gerade wieder einen Engpass gibt. WUs zu weiteren Bindungszielen sind in Vorbereitung.

Meilensteine im Januar
Hallo zusammen!

Der Jahresbeginn war produktiv: 1000 aktive Benutzer und 4000 Rechner!
Mit eurer Hilfe beenden wir das zweite Bindungsziel und arbeiten auf die nächsten Bindungsziele sowie zukünftige Tests im Nasslabor hin.
Danke an alle und gute Gesundheit.

Hoarfrost und Natalia
18.01.2021, 7:24:36 MEZ

Originaltext:

Milestones of January
Hello everyone!

The beginning of the year was productive: 1000 active users and 4000 computers!
With your help, we are finishing the 2nd target, working towards next targets and prospective testing in a wet-lab.
Thanks to everyone and good health.

Hoarfrost and Natalia.
18 Jan 2021, 6:24:36 UTC

[nexiagsi16v]

Es gibt wieder WUs....

*Edit: Achtung...die WUs haben wohl nur eine Haltbarkeit von 1 Tag! Ich weiß nicht ob das bei den anderen WUs auch so war/ist. Ich hab hier zumindest eine Curie für Windows mit nur 24h.*

[Felix_M_]

Es gibt wieder WUs....

*Edit: Achtung...die WUs haben wohl nur eine Haltbarkeit von 1 Tag! Ich weiß nicht ob das bei den anderen WUs auch so war/ist. Ich hab hier zumindest eine Curie für Windows mit nur 24h.*

Das von dir aufgeführte Target ist noch das Erste, das Zweite steht darunter.
Ich vermute, bei dir sind resends angekommen, denn neue wus sind schon seit ein par tagen aus.

edit: es sind doch schon wus zum nächsten Target verfügbar

[nexiagsi16v]

Jup, hab das schon korrigiert. Dachte V3 ist Target 3...und ja, Target_3 WUs sind es mit dem einen Tag Deadline. Ich vermute man hat alle auf die 24h gesetzt, bis alle Target_2 durch sind. Ich hab grad gesehen, das die Target_3 Curie zum Ende hin schneller werden...da springen die Prozente regelrecht. So kamen bei mir anstelle von 60 Minunten, nur 43 raus.

[nexiagsi16v]

Die WUs haben keinen Checkpoint...Rechner aus und sie fangen wieder bei 0 an.

[AxelS]

Es sind nicht die WUs, die keine Checkpoints haben, es sind die beiden Programme (cmdock, rxdock), die keine Checkpoints erzeugen/verwalten.

[taurec]

Habe meine Rechner mal auf NNW gesetzt, produzieren fast nur noch:
"Fertig, Bestätigung nicht möglich"
Überprüfung ohne Ergebnis (611) · Gültig (225) · Ungültig (677)

[AxelS]

Meine Rechner habe ich auch auf NNW bei SiDock gesetzt. Vermutlich läuft der Validator beim Projekt nicht mehr richtig...