15. Pentathlon 2024 - Marathon - PrimeGrid: nur das Subprojekt Cullen Prime Search LLR (CUL)

[FritzB]

Ladies and Gentleman!
Please start your engines!

Für alle Fragen, die zum Marathon (Primegrid Subprojekt Cullen Prime Search LLR) im Rahmen des Pentathlon 2024 auftreten, soll dieser Thread dienen.

Die Disziplin "Hindernislauf" des Pentathlon 2023 wurde wieder durch den altbekannten Marathon ersetzt. D.h. wer einfach dauerhaft mitrechnen möchte, ohne ständig etwas anpassen zu müssen, ist hier gut aufgehoben.

Offizielle Ankündigung:

Discipline stats Marathon | seti-germany.de

www.seti-germany.de

Zeitraum:
Start: 05.05.2024 um 0:00 Uhr (UTC) bzw. 2:00 Uhr (MESZ)
Ende: 19.05.2024 um 0:00 Uhr (UTC) bzw. 2:00 Uhr (MESZ)

Es kann ab sofort gerechnet werden, Hochladen aber erst ab dem 05.05. um 02:00 MESZ!

Projektseite:
https://www.primegrid.com/

Nach der Registrierung nicht vergessen, dem Team beizutreten!

Unser Team mit Beitrittslink:
https://www.primegrid.com/team_display.php?teamid=499
Unserem Team bitte beitreten, bevor fertige Arbeit hochgeladen wird. Dazu auf der Teamseite ins Projekt einloggen und dann "Team beitreten (join team)" wählen. Teamwechsel während des Wettkampfes sind verpönt!

Konto erstellen:
Einfach über den BOINC-Manager beim Projekt mitmachen.
Bei BOINC-Versionen älter als 5.2 hier anmelden:
https://www.primegrid.com//create_account_form.php?next_url=

Besonderheiten:

• Es wird nur das Unterprojekt Cullen Prime Search LLR (CUL) in die Wertung einbezogen.
• Die WUs sind Multi-Thread und sollten auch auf mehreren Kernen berechnet werden, da sonst die Laufzeit viele Tage andauern kann. Dazu in den PrimeGrid-Einstellungen unter "Job Control and Multi-threading"
  bei "Multi-threading: Max # of threads for each task" je nach Anzahl der eigenen Kerne einen Wert eintragen.
• Quorum 1, d.h. die Punkte werden (fast) sofort gutgeschrieben. Es gibt wie bei anderen PG Unterprojekten eine sehr kurz laufende Bestätigungs-WU "Proof Task" bei einem Wingman, die aber nur wenige Sekunden bis Minuten läuft.

Wer nicht extra einen eigenen Account bei dem Projekt erstellen will, kann über den schwachen Kontoschlüssel des P3D-Cluster mitrechnen.

Schwachen Schlüssel für den P3D Cluster:

77312_3a6cc128f73e9ec60939e328f7b4bb32

<account>
    <master_url>http://www.primegrid.com/</master_url>
    <authenticator>77312_3a6cc128f73e9ec60939e328f7b4bb32</authenticator>
    <project_name>PrimeGrid</project_name>
<project_preferences>

Datei als account_www.primegrid.com.xml speichern unter:
Win C:\ProgramData\BOINC\
Linux /var/lib/boinc-client/


Hosts-Eintrag:

127.0.0.1 www.primegrid.com
::1 www.primegrid.com

Bunkern:
Die Laufzeit der WUs ist sehr lang. Daher reicht es, für den Marathon über die regulären Einstellungen Arbeit zu bunkern.

 

[JagDoc]

Das Projekt unterstützt auch ARM-Systeme. Man kann also Systeme wie Raspberry Pi oder Odroid mitrechnen lassen.

Für das Unterprojekt gibt es keine App für ARM.

 

[koschi]

Ja schade

Schwacher Schlüssel vom P3D Cluster: 77312_3a6cc128f73e9ec60939e328f7b4bb32

 

[sompe]

Kennt jemand eine Referenzlaufzeit für 8 Threads an der man sich orientieren könnte?
Bei mir läuft ne Ladung Test WUs die nach 50 Minuten erst bei 0,58% ist.

 

[Darkmind]

Nicht direkt eine Referenz.

Ein i7-8700k (12 Threads) hat jetzt nach 25min 1,5% und eine vorausichtliche Laufzeit von 26 Stunden.

 

[bobmain]

Guten Morgen, es läuft tatsächlich quälend langsam. Die ersten WU(2CPU) haben gerade mal ca. 4% nach 4h bei 3,9Ghz auf einem 5800X3D geschafft.
Habe jetzt im Projekt auf 8 Threads umgestellt, mal sehen was da mein 3900er so reißen kann, zumindest scheint er sich ganz schnuckelig bei 3,7GHz einzupegeln.
Ich werde das beobachten......

 

[sompe]

@Darkmind
Bei meinem TR 3990X (aktuell 1,13% nach 1,5h) werden bisher fast 6 Tage prognostiziert.

 

[JagDoc]

Bei PrimeGrid SMT/HT ausschalten (50% CPU-Nutzung)
Bei 39xx, 59xx und 79xx 2WUs auf 6 bzw 8 Kernen rechnen.

7945HX@45W mit 2WU auf je 8 Kernen nach 3,5 Stunden 33%.

 

[sompe]

Kommt es mit SMT zu mehr als einer Verdoppelung der Laufzeit?
Sonst bringt dessen Abschaltung ja eher wenig wenn dadurch nur halb so viele WUs laufen.

 

[JagDoc]

Kommt es mit SMT zu mehr als einer Verdoppelung der Laufzeit?
Sonst bringt dessen Abschaltung ja eher wenig wenn dadurch nur halb so viele WUs laufen.

Ich hab vor kurzem mal getestet mit nem 5700G (bei anderem Subprojekt):
5700G 8C 14,160.03 107,395.00 11,587.73
5700G 15C 14,993.58 203,472.60 11,568.23

Bei z.B. 8C/16T mit 2 WU auf 8 Kernen paßt nur 1 WU in den L3 Cache und es wird auf den Arbeitsspeicher ausgelagert.

 

[sompe]

Unterschiedliche Subprojekte sind bei solchen Vergleichen immer ungünstig weil jedes anders reagieren kann.
Bei einer reinen Verdoppelung der Rechenzeit durch Aktivierung von SMT würde ich aber nicht von einem Cache Problem ausgehen denn das spricht eher dafür das der erste Thread nicht genug Rechenkapazität für den zweiten übrig läßt.
Geht der Einbruch allerdings darüber hinaus spricht es durchaus dafür. Bei einem L3 Überlauf würde dann aber z.B ein X3D anders reagieren.

 

[FritzB]

So, hab den Startpost aktualisiert. War heute Nacht mal schnell aus einem früheren Penta-Thread erstellt und für die Feinheiten war es mir dann doch zu spät

 

[sompe]

So, ich habe mal die Prozessorzahl auf 50% gesetzt und das scheint mehr als eine Halbierung der Rechenzeit zu sein.
Wo er vorher in 2:25h 1,72% schaffte sind es jetzt 7,85% nach 5:25h.
Das wären in den 3 Stunden zusätzliche 6,13%, also ca. eine Drittelung der Rechenzeit also SMT aus. ^^

 

[JagDoc]

Quorum 1, d.h. die Punkte werden sofort gutgeschrieben (evtl. gibt es wie bei anderen PG Unterprojekten eine sehr kurz laufende Bestätigungs-WU bei einem Wingman, was ich aber bisher nicht sehen konnte).

Die WUs werden durch kurze Proof-Tasks validiert.

 

[koschi]

3900X, 5700G und 2 x 9700T sind schon fleißig

 

[NEO83]

So, ich habe mal die Prozessorzahl auf 50% gesetzt und das scheint mehr als eine Halbierung der Rechenzeit zu sein.
Wo er vorher in 2:25h 1,72% schaffte sind es jetzt 7,85% nach 5:25h.
Das wären in den 3 Stunden zusätzliche 6,13%, also ca. eine Drittelung der Rechenzeit also SMT aus. ^^

Aber woran liegt es denn dann? Ist es wirklich ein Problem mit dem L3 Cache und ein X3D könnte das Problem nicht haben oder liegt das Problem eher wo anders?

 

[MagicEye04]

LOL.
Nachdem ich nun auf 50% gestellt habe, sinkt der Takt von 3,2 auf 2,1GHz.
Ich fürchte, die werden damit eher noch langsamer fertig.

 

[NEO83]

Also auch mit einem 7800X3D bleiben die Probleme mit der Laufzeit ... nicht so extrem wie mit einem ohne 3D Cache aber immer noch spürbar

 

[MagicEye04]

Ich habe mal 15W nachgefüllt, damit sind es schon 2,8GHz.
Nebenbei geprüft, ob die Checkpoints funktionieren. Ja, aber 15-40 Minuten sind schon recht lang.

 

[sompe]

Aber woran liegt es denn dann? Ist es wirklich ein Problem mit dem L3 Cache und ein X3D könnte das Problem nicht haben oder liegt das Problem eher wo anders?

Das ist die Frage woran es denn nun genau liegen wird denn es gibt ja noch 2 weitere Cache Ebenen und beim X3D gibt es nur den größeren L3 Cache.
Eine weitere Möglichkeit könnten aber auch die genutzten CPU Befehlssätze sein. Kommt vielleicht AVX2 oder gar 512 intensiv zum Einsatz? Womöglich kann sich die Doppelbelegung auch da negativ auswirken.

Ist halt fröhliches Rätselraten das nur der Projektbetreiber selbst beantworten könnte.

 

[Outlaw9876]

Was stellt man denn am besten auf nem ollen Ryzen 3 2200G ein?

Der hat nur 4 Kerne, kein SMT und nur 4 MB L3-Cache.

Nach ca. 12 Stunden sieht das so aus:

 

[Crashtest]

Prüf mal ob MT an ist !!!


Wenn da 1 steht wird das nix

 

[MagicEye04]

Der hat nur 4 Kerne

Und die sollten zusammen auch nur eine WU knuspern.

 

[Crashtest]

dann sollte da nicht 1 sondern 4 stehen!

wenn da 1 steht läuft jede Wuze auf 1 Fred
wenn da 8 steht (maximum) läuft jede Wuze auf 4 Freds wenn 4 Fred-CPU

 

[sompe]

Hat mal jemand getestet ob das Teilprojekt auf Windows oder Linux besser läuft?
Ich habe es mal mit auf meinem 5800X3D unter Windows und mit allen 16 Threads (2x 8er WUs) gestartet und da läuft es erheblich flotter. Gedrosselt auf 65W soll er so ca. 26 Stunden für beide WUs benötigen.