13. Pentathlon 2022: Querfeldein (Primegrid)

[herby44]

Ich habe hier zwei Hauptinstanzen einmal Mint einmal Win da werde ich über 1800 Primeln nicht los(melden)
bei beiden funktioniert die jeweils zweite Instanz einwandfrei ich habe beide Systeme angehalten und neu gestartet nichts hat geholfen, die Primeln haben sie noch hochgeladen können sie aber nicht melden.

Project communication failed: attempting access to reference site
Scheduler request failed: Failure when receiving data from the peer
Internet access OK - project servers may be temporarily down.

 

[sompe]

Es macht bei mir aber schon ein Unterschied bei Prime, ob ich 12, 16 oder 20 Numbers parallel rechne, das verstehe ich nicht.

Welcher Prozessor ist es überhaupt?
Bei aktivierten SMT müssen sich beide Threads die Rechenzeit auf dem Kern teilen. Deshalb erhöht sich bei Aktivierung die Laufzeit der WUs aber dafür laufen eben auch doppelt so viele. EIn Leistungszuwachs durch SMT entsteht lediglich dadurch das die Laufzeiterhöhung weniger stark ausfällt als die Erhöhung der gleichzeitig laufenden WUs.
Die Verteilung der Rechenzeit der beiden Threads pro Kern muss noch nicht einmal gleichmäßig sein, was ziemlich egal ist wenn überall die gleichen WUs laufen aber bei unterschiedlichen WUs kann das sehr wohl bedeutsam sein wenn dem ergiebigeren Projekt, wie z.B. den GPU WUs, dadurch die benötigte CPU Laufzeit abgegraben und die WU dadurch ausgebremst wird.

Hast du es also schonmal mit der Deaktivierung von SMT versucht?

Na eigentlich ist die RAM Anbindung schlechter: Quadchannel für 128 Threads
Ich rechne übrigens auf Linux!

Bei mir waren unter Linux 4 WUs pro GPU auf den VIIs erheblich langsamer als 2 WUs und was noch viel wichtiger ist auch erheblich langsamer als 4 WUs pro GPU unter Windows. mit 2 WUs pro GPU waren die Laufzeiten unter Linux und Windows vergleichbar. Da scheint es bei meiner Config eine Unverträglichkeit zu geben.

 

[erde-m]

Ich habe mal ein paar neue Zahlen für Nero`s Tabelle:
VII 295s 2 WU 1.974.606 Cr./Tag -> Optimum
VII 484s 3 WU 1.805.295 Cr./Tag

69XT 532 6 WU 3.284.824 Cr/Tag

Update:
VII 289s 2 WU 2.015.601 Cr./Tag
EDIT: 69XT 351s 4 WU 3.319.138 Cr./Tag

 

[Nero24]

@erde-m

was hast Du da jetzt an den Optionen geschraubt? Ist die Karte nun OC? Das sollte als Info mit rein, sonst wundert sich ein Stock-User, warum seine Karte das nicht schafft.

 

[Krümel]

Habe auch mal wieder ein Primelbeet abgeerntet.

 

[erde-m]

@erde-m

was hast Du da jetzt an den Optionen geschraubt? Ist die Karte nun OC? Das sollte als Info mit rein, sonst wundert sich ein Stock-User, warum seine Karte das nicht schafft.

Nix getunt.
Stock@AMD (beides Originale) unter Linux Mint 20.03 mit aktuellen AMD Treiber, nicht mal UV
Durch Universe-Aussetzer sind die CPUs aber exclusiv für die GPUs da

ABER - gerade bemerkt: (Beitrag oben editiert)
2 WU bei der 6900XT haben sich aufgehangen - es waren also nicht 6 sondern nur 4 gleichzeitig in Arbeit

 

[Nero24]

Project communication failed: attempting access to reference site
Scheduler request failed: Failure when receiving data from the peer
Internet access OK - project servers may be temporarily down.

Hm, seltsam. Ist das eine aktuelle BOINC-Version? Ich hatte bei einigen Windows-Installationen auch das Problem, dass Numberfields zuerst problemlos lief, als ich dann aber Primegrid verbinden wollte, ging das nicht mit der alten BOINC-Version und ich musste sie aktualisieren. Allerdings hattest Du die Instanz ja offenbar bereits verbunden und kannst jetzt nicht melden

 

[Nero24]

 

[Nero24]

Bei Primegrid als Quorum-2-Projekt ist es ja vorteilhaft, wenn man sich gleich am Anfang so viele WUs geholt hat, dass sie bis zum Ende der Disziplin reichen und nicht ständig nachholt. Das reduziert das Pending.

Aber: macht bitte nicht den selben Denkfehler wie ich im vergangenen Jahr bei Einstein@home, wo ich den letzten Tag noch mitgezählt habe. Der letzte Tag hat aber nur noch 2 Stunden, dann ist die Disziplin zu Ende. Deswegen hatte ich mir auf 4 Maschinen WUs für einen ganzen Tag zu viel geladen. Zum Glück haben mir dann ein paar Teamkollegen geholfen, zu viel gebunkerte Instanzen abzuarbeiten. Bei einem Quorum-2-Projekt "darf" man die ja nicht einfach verfallen lassen, denn im schlimmsten Fall ist der Wingman ein Teamkollege, den man damit aus dem Rennen nimmt.

Daher rechnet bitte hoch, ob Ihr die gezogenen WUs tatsächlich zuverlässig vor Ende der Disziplin schafft. Falls nicht, bitte nach Freiwilligen Ausschau halten, die Euch helfen beim Abarbeiten der Instanzen, oder bald möglichst abbrechen, damit der Projekt-Server die WUs erneut versenden kann und zumindest die Chance besteht, dass sie noch bearbeitet werden vor Ende.

Dasselbe gilt für jene, die bei offenen Türen mit Puffer rechnen. Bitte rechtzeitig auf "Keine neuen Aufgaben zulassen" stellen, damit nicht das gleiche passiert und Ihre Eure Wingmen, im schlimmsten Fall einen Teamkollegen, aus dem Spiel nehmt. Ziel muss sein, am 14.05. um 1:59 Uhr MESZ keine Primegrid-WUs mehr übrig zu haben.

 

[gruenmuckel]

Bei Primegrid als Quorum-2-Projekt ist es ja vorteilhaft, wenn man sich gleich am Anfang so viele WUs geholt hat, dass sie bis zum Ende der Disziplin reichen und nicht ständig nachholt. Das reduziert das Pending.

Aber: macht bitte nicht den selben Denkfehler wie ich im vergangenen Jahr bei Einstein@home, wo ich den letzten Tag noch mitgezählt habe. Der letzte Tag hat aber nur noch 2 Stunden, dann ist die Disziplin zu Ende. Deswegen hatte ich mir auf 4 Maschinen WUs für einen ganzen Tag zu viel geladen. Zum Glück haben mir dann ein paar Teamkollegen geholfen, zu viel gebunkerte Instanzen abzuarbeiten. Bei einem Quorum-2-Projekt "darf" man die ja nicht einfach verfallen lassen, denn im schlimmsten Fall ist der Wingman ein Teamkollege, den man damit aus dem Rennen nimmt.

Daher rechnet bitte hoch, ob Ihr die gezogenen WUs tatsächlich zuverlässig vor Ende der Disziplin schafft. Falls nicht, bitte nach Freiwilligen Ausschau halten, die Euch helfen beim Abarbeiten der Instanzen, oder bald möglichst abbrechen, damit der Projekt-Server die WUs erneut versenden kann und zumindest die Chance besteht, dass sie noch bearbeitet werden vor Ende.

Dasselbe gilt für jene, die bei offenen Türen mit Puffer rechnen. Bitte rechtzeitig auf "Keine neuen Aufgaben zulassen" stellen, damit nicht das gleiche passiert und Ihre Eure Wingmen, im schlimmsten Fall einen Teamkollegen, aus dem Spiel nehmt. Ziel muss sein, am 14.05. um 1:59 Uhr MESZ keine Primegrid-WUs mehr übrig zu haben.

Wir könnten uns abstimmen als Team gleichzeitig WUs zu holen. Sollten wir dann nicht mit erhöhter Wahrscheinlichkeit gegenseitig Wingmen sein?
[automerge]1652166265[/automerge]
Zur Erinnerung:
RX480 8:58 Minuten | 1 WU parallel | 538 Sekunden | 160,59 WUs pro Tag | 541365 Punkte pro Tag | gruenmuckel

Wo ich die Liste sehe:

Meine RX480 ist etwas flotter als die von eratte.
8:58 Minuten pro WU.

Anhang anzeigen 50015

 

[Nero24]

Wir könnten uns abstimmen als Team gleichzeitig WUs zu holen. Sollten wir dann nicht mit erhöhter Wahrscheinlichkeit gegenseitig Wingmen sein?

Ja, aber das sagen wir seit Jahren, machen es dann aber irgendwie doch nicht. Ich hab meine Bunker jedenfalls schon

Aber es kommt ja wohl mindestens noch ein weiteres Quorum-2-Projekt (Stadtlauf vermutlich). Vielleicht kriegen wir das ja dann mal gebacken

Edit:

Zur Erinnerung:
RX480 8:58 Minuten | 1 WU parallel | 538 Sekunden | 160,59 WUs pro Tag | 541365 Punkte pro Tag | gruenmuckel

Hab obige Liste nochmal erweitert, danke

 

[ydeeps]

@sompe , ist ein 5950X auf MSI B550 A-Pro, mit 32GB Ram unter W10.

 

[sompe]

@ydeeps
Dann dürfte diese Skalierung recht einfach erklärbar sein.
Bis 12 CPU WUs bekommen bekommen alle WUs, also auch die 4 GPU WUs, ihren eigenen Kern.
Laufen mehr WUs dann müssen dann müssen sich 2 WUs die Rechenzeit des Kerns teilen und schiebt der Sheduler die WUs fröhlich über alle Kerne hinweg ist jeder mal dran etwas Federn zu lassen und könnten so auch die GPU WUs ausbremsen. In dem Fall muss man einfach testen ob es nicht sinnvoller ist SMT abzuschalten.

 

[ydeeps]

Und warum ist es bei MagicEye dann anders?

 

[sompe]

@ydeeps
Weil es schon reicht das z.B. der Sheduler anders arbeitet indem z.B. der GPU WU mehr Rechenzeit zugeordnet wird und diese dann wiederum ausreichend ist um den Einbruch zu verhindern.
Bei einer festen Kern Zuordnung läuft dann eben die CPU WU entsprechend langsamer die sich den Kern mit der GPU WU teilt, rauchen die fröhlich von Kern zu Kern kann sich der Einbruch auf alle laufenden CPU WUs verteilen.

Das gleiche Problem kann übrigens auch bei einem Mix von CPU Projekten entstehen. Ich habe schon erlebt dass die CPU WU eines Projekts die eines anderen so massiv ausgebremst hatte das sich deren Laufzeit vervielfacht hatte.
Ich bin mir nicht sicher aber ich glaube richtig fies konnte es werden wenn sich eine VM WU den Kern mit einer normalen CPU WU teilt aber ich weiß nicht mehr wer dann benachteiligt wurde.

Wie gesagt, das muss man bei Bedarf einfach mal austesten was am Ende mehr bringt.

 

[Outlaw9876]

Hier ein paar Werte für die Sammlung:

RX 570 --> Sieve: 668 Sek. / 11:08 Min // Wieferich: 4639 Sek. / 1:17:19 Stunden (jeweils 1 WU)

RX 6600XT --> Sieve: 498 Sek. / 8:18 Min (2 WUs gleichzeitig) // Wieferich: 1.600 Sek / 26:40 Min (1 WU)

Wenn ich der RX 6600XT nur 2 CPU-Threads pro WU gebe erhöht sich die Laufzeit bei den Sieve-WUs auf 635 Sek. / 10:35 Min (2 WUs gleichzeitig) - also min 4 Threads bzw. 2 Kerne geben.

 

[MagicEye04]

Und warum ist es bei MagicEye dann anders?

Linux bekommt das Core jumping evtl. besser hin

 

[erde-m]

Eine Auffälligkeit habe ich bei der 6900XT beobachtet:
Ich dachte nach 4 und 6 WU mal zu sehen, wie es sich mit 5 WU verhält- meine Vermutung, das es recht optimal sein sollte...
Denkste hier hat nicht immer, aber oft, eine der 5 WU seeehr viel länger gebraucht.
Nach dem Wechsel auf 6 WU und alles ging wieder sehr gleichmäßig.

 

[Mente]

Hi Erde mir ist aufgefallen wenn ich einen Kern ganz Frei (31 von 32) lassen (per 99%) dann pendeln sich die 6 Wus bei 505-510sek ein ich befürchte die CPU zu 100% auszulasten bremst doch etwas.
lg

 

[NEO83]

Laptop ist da und bekommt jetzt kurz windows und dann geht er direkt erst mal Primeln und Nummernfelder ...
um den Rest kümmere ich mich später

 

[erde-m]

@Mente
Die Vermtung hatte ich auch erst. Selbst mit 80% war der Effekt nicht weg. Habe Universe angehalten, keine Besserung... erst die Anpassung der xml hat dem Treiben ein Ende gemacht.

 

[Mente]

naja das ist mir auch nur aufgefallen da der Rechner CPU mässig leer gelaufen war heute, da Uni nichts mehr gesendet hat ...

 

[NEO83]

wie kann ich beide GPUs unterschiedlich ansteuern?
[automerge]1652199537[/automerge]
Aktuell rechnet nur die iGPU ... das bringt halt nichts ...

 

[Krümel]

Aktuell rechnet nur die iGPU

In der CC_Config.xml muss der Eintrag
<use_all_gpus>1</use_all_gpus>
Vorher BOINC beenden und danach wieder starten.

@MagicEye04 : Gib mal ein bisschen Gas, Du bist bei diversen WU mein Wingman.

 

[NEO83]

Ich weiß man musste die erstellen aber wie sah die nochmal aus? xD
[automerge]1652200786[/automerge]

<cc_config>
    <options>
    <use_all_gpus>1</use_all_gpus>
    </options>
</cc_config>

aktuell sieht die so aus aber er sagt folgendes:

10.05.2022 18:37:41 |  | cc_config.xml not found - using defaults

[automerge]1652202181[/automerge]
Ich bin einfach zu doof ... jetzt hat er die zwar eingelesen aber jetzt wird nur noch eine WU bearbeitet mit 1 CPU und 0.5 GPU

Man man man
[automerge]1652202229[/automerge]

10.05.2022 19:01:35 |  | Starting BOINC client version 7.16.20 for windows_x86_64
10.05.2022 19:01:35 |  | log flags: file_xfer, sched_ops, task
10.05.2022 19:01:35 |  | Libraries: libcurl/7.47.1 OpenSSL/1.0.2s zlib/1.2.8
10.05.2022 19:01:35 |  | Data directory: C:\ProgramData\BOINC
10.05.2022 19:01:35 |  | Running under account akwop
10.05.2022 19:01:35 |  | OpenCL: AMD/ATI GPU 0: AMD Radeon(TM) Graphics (driver version 3380.6 (PAL,HSAIL), device version OpenCL 2.0 AMD-APP (3380.6), 7177MB, 7177MB available, 1613 GFLOPS peak)
10.05.2022 19:01:35 |  | OpenCL: AMD/ATI GPU 1: AMD Radeon RX 6600M (driver version 3380.6 (PAL,LC), device version OpenCL 2.0 AMD-APP (3380.6), 8176MB, 8176MB available, 7802 GFLOPS peak)
10.05.2022 19:01:35 |  | Windows processor group 0: 12 processors
10.05.2022 19:01:35 |  | Host name: Legion
10.05.2022 19:01:35 |  | Processor: 12 AuthenticAMD AMD Ryzen 5 5600H with Radeon Graphics [Family 25 Model 80 Stepping 0]
10.05.2022 19:01:35 |  | Processor features: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 htt pni ssse3 fma cx16 sse4_1 sse4_2 movebe popcnt aes f16c rdrandsyscall nx lm avx avx2 sse4a osvw wdt topx page1gb rdtscp fsgsbase bmi1 smep bmi2
10.05.2022 19:01:35 |  | OS: Microsoft Windows 11: Professional x64 Edition, (10.00.22000.00)
10.05.2022 19:01:35 |  | Memory: 13.86 GB physical, 16.48 GB virtual
10.05.2022 19:01:35 |  | Disk: 893.53 GB total, 845.61 GB free
10.05.2022 19:01:35 |  | Local time is UTC +2 hours
10.05.2022 19:01:35 |  | No WSL found.
10.05.2022 19:01:35 |  | VirtualBox version: 6.0.14
10.05.2022 19:01:35 | PrimeGrid | Found app_config.xml
10.05.2022 19:01:35 |  | Config: use all coprocessors