12. Pentathlon 2021 - SiDock (Marathon)

Nero24

Administrator
Teammitglied
Mitglied seit
01.07.2000
Beiträge
24.066
Renomée
10.445
  • BOINC Pentathlon 2019
  • BOINC Pentathlon 2020
  • BOINC Pentathlon 2018
  • BOINC Pentathlon 2021
Für alle Fragen, die zum Marathon (SiDock) im Rahmen des Pentathlon 2021 auftreten, soll dieser Thread dienen.

Zeitraum:
Start: 05.05.2020 um 0:00 Uhr (UTC) bzw. 2:00 Uhr (MESZ)
Ende: 19.05.2020 um 0:00 Uhr (UTC) bzw. 2:00 Uhr (MESZ)

Ankündigung der Pentathlon-Initiatoren:

Projektseite:
https://www.sidock.si/sidock/

Konto erstellen:
https://www.sidock.si/sidock/signup.php (Einladungscode: Crunch_4Science)
Alternativ über den BOINC-Manager beim Projekt mitmachen

Unser Team mit Beitrittslink:
https://www.sidock.si/sidock/team_display.php?teamid=9
Unserem Team bitte beitreten bevor der Pentathlon startet bzw. bevor Punkte erzielt wurden. Dazu auf der Teamseite ins Projekt einloggen und dann "Team beitreten (join team)" wählen. Teamwechsel während des Wettkampfes sind verpönt!

Schwacher Schlüssel für den P3D-Cluster:
Der schwache Kontoschlüssel für dieses Projekt:
Code:
 942_585e7582dcf08f0798b93f2667c00c93

Lokale Dateien:
account_www.sidock.si_sidock.xml
Code:
<account>
    <master_url>https://www.sidock.si/sidock/</master_url>
    <authenticator>942_585e7582dcf08f0798b93f2667c00c93</authenticator>
</account>
Windows: C:\ProgramData\BOINC\
Linux: /var/lib/boinc-client/

Weitere Informationen in unserem DC-Wiki:

Besonderheiten:
  • Quorum=2 -> Pending (ab dem 17.05. möglichst keine frischen WUs mehr holen, sondern vorher genügend holen, damit sie bis zum Ende reichen)
  • Haltbarkeit der WUs aktuell 3 2 Tage. Bunkern ergibt also erst ab 02.05. 03.05. 02:01 Uhr MESZ Sinn.
  • Das Projekt rückt an frische Clients nur wenig WUs heraus am Anfang, sodass es sinnvoll ist, schon vor dem schließen der Bunkertüren ein paar gültige WUs abzuliefern, um überhaupt genügend WUs zum Bunkern zu erhalten.
  • Trotz Ankündigung haben die WUs keine Checkpoints! Wer zwischendurch den PC herunterfährt oder BOINC beendet, muss die angefangenen WUs wieder von vorne berechnen. Standby oder Ruhezustand funktioniert aber.
  • Windows ist ggü. Linux im Vorteil bei diesem Projekt, und alte Ubuntu 14 schrotten die WUs, da Bibliotheken fehlen.
Hostseintrag zum Bunkern:
Code:
#SiDock
127.0.0.1 www.sidock.si
::1 www.sidock.si

Bunkern per Instanzen statt via Hostseintrag (empfohlen):
 
Zuletzt bearbeitet:
Moin,

so, SiDock ist nun auch offiziell als Marathon-Projekt angekündigt worden.

Noch lohnt es sich allerdings nicht zu bunkern, da die SiDock-WUs nur eine Haltbarkeit von 3 Tagen haben. Erst ab 02.05. ab 02:00 Uhr MESZ ist bunkern sinnvoll. Da SiDock für Bunker aber nur dann ausreichend WUs herausrückt, wenn das Gerät schon ein paar gültige abgeliefert hat, kann es nicht schaden, SiDock schon mal anzufangen mit geöffneten Bunkertüren. :)


Also schon mal anfangen Sidock zu rechnen?
 
Zum Optimieren der SiDock-Bunkerein habe ich es wie folgt verstanden:

(Ist eher für die "Hin-und-wieder-Cruncher" gedacht und nicht für die Superprofis hier :-))

Start ist am 05.05. 0:00 UTC

1619769373286.png
Das bedeutet, dass es am 05.05. mitten in der Nacht um 2 Uhr deutscher Zeit losgeht. Alle hochgeladenen WUs ab 2 Uhr zählen also.

Aktuelle Haltbarkeit der Wus bei SiDock ist 72 Stunden. 05.05. 2 Uhr - 72 Stunden = 02.05. 2 Uhr.

Mit Bunkern kann man daher erst effektiv in der nacht von Samstag auf Sonntag um 2 Uhr beginnen.

Wenn man zu diesem Stichtag anfängt, muss man dann natürlich auch am 05.05. um 2 Uhr hochladen, sonst verfallen die WUs. Daher sollte jeder auch einplanen, wann man persönlich am 05.05. überhaupt hochladen kann. Wer es also realistisch erst um 7 Uhr am 05.05. schafft, die Schleusen freizugeben, der sollte auch erst Sonntag morgen um 7 Uhr den Weinkeller vollmachen.

Weitere Erschwernis: DiDock teilt pro Thread und Instanz nur 2 WUs als Maximum zu. Zudem gibt es ein globales Maximum von 128 oder 256 Threads, d.h. mehr als diese Anzahl bekommt man auch mit 1000 CPUs nicht . Eine WU läuft je nach Rechner mind. 5 - 10 Stunden. Daher kann man mit einer Instanz (je nach Rechner nur 10 - 20 Stunden bunkern). Daher muss man ...
a) mehrere Instanzen anlegen
und/oder
b) per ncpus in app_config mehr Threads vorgaukeln

Falls jemand einen Fehler findet, berichtige ich dass hier gern. Sollen wir das noch irgendwo prominenter aufhängen?

(Ergänzung: diesen Beitrag hatte ich in einem anderen Thema geschrieben, er wurde dann verschoben, daher ein Großteil der Informationen doppelt gemoppelt)
 
Zuletzt bearbeitet:
Schwacher Kontoschlüssel des Clusters:
942_585e7582dcf08f0798b93f2667c00c93

account_www.sidock.si_sidock.xml
Code:
<account>
    <master_url>https://www.sidock.si/sidock/</master_url>
    <authenticator>942_585e7582dcf08f0798b93f2667c00c93</authenticator>
</account>
 
@koschi ich kann deine Anleitung für Dein Instanzenskript grad nicht finden *kopfkratz Würde das gerne noch im Startpost verlinken

Vergiss es, sehe grad, es gibt die Anleitung mittlerweile ja im DC-Wiki :D
 
Zuletzt bearbeitet:
Die SiDock-Anwendung (zumindest die unter Windows) macht massiv Gebrauch von AVX:
sidock.png

Das heißt, Prozessoren mit 256-Bit breiter FPU dürften deutlich im Vorteil sein in Sachen Berechnungsdauer. Bei AMD also Ryzens ab Zen 2. Bulldozer-spezifische Befehlssätze wie FMA4 oder XOP werden ebensowenig genutzt wie 3DNow! alter Athlon 64 CPUs.
 
Ja, das hatte ich schon bei der letzten Challange gemerkt. Der Picasso in meinem Notebook kam nicht ansatzweise an die Zen 2 im Desktop heran.
 
Sagt mal haben die immer noch keine Checkpoints eingefügt?
Das wäre für mich dann sogar fast ein Grund KEIN Marathon zu rechnen dieses mal ... ich muss zwischendurch halt immer mal ins andere OS booten womit jedes mal der Fortschritt weg wäre ...
 
Wollen sie noch implementieren. Ob sie es bis zum Pentha schaffen... *noahnung*
 
Ja bei 8-10h Laufzeit ist das schon echt hard wenn mal was ist und man verliert vllt nen viertel Tagesoutput weil die keine Checkpoints haben, generell kein Problem aber dann kannste halt nur ne Laufzeit von 30-60 Minuten haben dann kümmert das keinen ....
Aktuell müsste ich rebooten aber ich kann nicht weil ich sonst 3h Berechnungszeit weg werfe -_-
Nungut ist halt aktuell leider so ... sonst muss ich mir halt ne VM Aufsetzen
 
So schlecht läuft Zen 1 aber nicht (Win 10).
Der Ryzen 3 2200G @ 3,5 GHz ist nicht viel langsamer als der Ryzen 9 3900x @ ca. 3,57 GHz mit SMT.
Ohne SMT wäre er wahrscheinlich ne ganze Ecke schneller, aber nicht soviel, dass es sich lohnen würde SMT abzuschalten.
Bullis braucht man aber nicht laufen lassen - 14,5 bis 15,5 Stunden auf einem Opteron 6338P @ 2,4 GHz.

 
Der Ryzen 3 2200G @ 3,5 GHz ist nicht viel langsamer als der Ryzen 9 3900x @ ca. 3,57 GHz mit SMT.
Naja, der 2200G unterstützt kein SMT und TROTZDEM ist die Laufzeit einer WU langsamer als beim 3900X mit SMT. Das ist schon enorm und dürfte der 256-Bit FPU (für AVX) des Zen 2 geschuldert sein :)
 
Jau, aber halt nicht so viel langsamer, als dass er als ungeeignet abgestempelt werden muss. ;)
Kein Vergleich zum Opteron.
Hoffentlich kommen auch noch Projekte, wo mein Altmetall etwas Grundrauschen beisteuern kann. *lol*
 
Jau, aber halt nicht so viel langsamer, als dass er als ungeeignet abgestempelt werden muss. ;)
Ne, natürlich nicht :) Aber es kommen ja noch 4 weitere Disziplinen, die sich über weite Phasen zeitlich überlappen, wo dann jeder überlegen muss, welches System er sinnvollerweise an welcher Front werkeln lässt. Insofern sollten wir im Hinterkopf behalten, dass Zen 2/3 bei SiDock deutliche Vorteile hat. Bei anderen Projekten, die evtl. kein AVX nutzen (werden wir dann sehen), wird der Unterschied zwischen älteren CPUs und den aktuellen Boliden deutlich kleiner sein.
 
@koschi offiziell gibt's ja keine ARM-apps von SiDock, z.B. für Raspi, Odroid, usw. Aber wie im SiDock-Thread zu sehen habt Ihr es ja anscheinend geschafft, SiDock auch auf ARM zum laufen zu kriegen. Wollen wir hier noch verraten wie oder sind die Laufzeiten so unterirdisch, dass es eh nicht lohnt? *kopfkratz
 
Im Gitlab repo des Projektes gibt es 32bit Binaries von CmDock. Die hab ich mit geeigneter app_info.xml und job.xml lauffähig gemacht, erfolgreich hochgeladene WUs wurden auch validiert. Ich habe auch ein 64bit CmDock kompiliert, das scheint aber signifikant langsamer zu sein als das armhf Kompilat vom Projekt.

Gerade wenn mehrere SiDock Threads laufen, schaffen ältere Boards nur eine WU innerhalb der Deadline. Auf dem C2 und Odroid XU4 laufen die ca. 2 Tage. Auf Odroid N2 1.5 Tage, auf Nvidia Jetson TK1 (aus 2014) sogar nur ein Tag.
Rapberry Pi3 wird die WUs (wenn überhaupt) nur knapp in der Deadline schaffen. RPi4 liegt auch bei ca. 2 Tagen.

Wer Lust hat die Anwendung mal zu testen meldet sich bitte. Bevor ich das vollkommen öffentlich stelle will ich erstmal gucken nach der Lizenz, was da mit reinzupacken wäre etc...
 
Die SiDock-Anwendung (zumindest die unter Windows) macht massiv Gebrauch von AVX:
Bei Ubuntu kann ich jetzt keine großen Unterschiede feststellen zwischen Zen1 und 2.
Der R7-1700@3,6GHz macht mit 15 Threads ca. 9.000cr am Tag,
der R9-3950X@78W/2,85GHz schafft mit 30 Threads 20.000cr/Tag. Also vielleicht 10% Vorteil.
(jeweils aus 15 WUs ermittelt) - wie sieht das bei Windows so aus?
 
Ich habe keine Zahlen im Kopf, aber ich meine mehrfach gelesen zu haben, dass Sidock
unter Windows etwas flotter ist als unter Linux. Vielleicht ist das auf das AVX zurückzuführen?
Sodass der Unterschied zwischen Zen1/+ und Zen2/3 unter Linux nicht so stark ausfällt wie unter Windows?
 
Die SiDock-Anwendung (zumindest die unter Windows) macht massiv Gebrauch von AVX:
Bei Ubuntu kann ich jetzt keine großen Unterschiede feststellen zwischen Zen1 und 2.
Der R7-1700@3,6GHz macht mit 15 Threads ca. 9.000cr am Tag,
der R9-3950X@78W/2,85GHz schafft mit 30 Threads 20.000cr/Tag. Also vielleicht 10% Vorteil.
(jeweils aus 15 WUs ermittelt) - wie sieht das bei Windows so aus?
Durch Zufall eine gemeinsam von uns bearbeitete WU gefunden. Vergleichbarer, da wir beide mit 3950X rechnen:

Du auf Linux mit 2,85 GHz: 24800 Sek
Ich auf Win mit 3,3 GHz: 18500 Sek

Der Zeitabstand (+26 %) ist nicht allein durch den Takt (-14 %) erklärbar.
 
Zurück
Oben Unten