Einstein@home - allgemeiner Austausch (News, Forenfunde, HowTo, etc.)

Also ich hab immernoch Berechnungszeiten von knapp 22.000 sec auf dem Ryzen.

App: Gravitational Wave Engineering run on LIGO O1 Open Data v0.06 () x86_64-pc-linux-gnu

Ist das jetzt schon die optimierte App?

Pro WU gibt's 1000 Cr.

Gruß,
Ritschie
 
Zuletzt bearbeitet:
Wo ich gerade mal ein wenig in den älteren Ergebnissen unseres Teams gestöbert habe auf der Suche nach Vergleichswerten, sah es eher nach 10 Stunden aus, also 30...35.000s.
Auch erschreckend fand ich, dass einige seit März auf Validisierung warten.
 
Ja 0.06 sind schon die neuen Versionen mit Lookup. Bei mir waren die 0.03er auch bei ~35000 Sekunden, 0.06 jetzt bei 19000-20000 Sekunden @ 3.2GHz.

--- Update ---

Rentiert sich damit das Rechnen per CPU im Vergleich zur GPU?

Was hat es eigentlich mit folgender Einstellung auf sich?
Code:
Run Linux app versions built with LIBC 2.15:
Sollte das aktiviert sein, oder nicht? Hat das Auswirkungen auf Rechenzeiten etc?

Gruß,
Ritschie

https://einsteinathome.org/content/vsyscall-now-disabled-latest-linux-distros?page=1#comment-162865

There is now a GW ("O1Spot1") application version that has been compiled on Ubuntu 10.04 with LIBC 2.15 and thus should fix this problem without enabling vsyscalls. As there is currently no BOINC Client that detects and reports the LIBC version, there is no way to automatically choose which app version to deliver to the clients. Instead there is a new project-specific setting "Run Linux app versions built with LIBC 2.15" that you have to enable manually. Please give it a try and see if it works.

While testing there is only an app version for the GW search, so you probably want to disable other applications (FGRP*) to prevent these from failing.

Mein Verständnis ist, das braucht es nur für alte Betriebssysteme, würde ich auf aktuellen Ubuntu oder SuSE nicht aktivieren, läuft ja auch auf "No".
LibC 2.15 war in Ubuntu 12.04 und 12.10.
 
Zuletzt bearbeitet:
Meine Engineering-WU v0.11 ist auch endlich fertig. Bissel über 10.000s auf der Tahiti. Also Faktor 11 langsamer als eine klassische GRPBS (967s).
Die brauch ich nicht noch mal.
 
Der "O1 Engineering run" ist wohl erstmal durch:

https://einsteinathome.org/de/content/gravitational-wave-all-sky-search-ligo-o1-open-data?page=8#comment-170783 schrieb:
We essentially stopped the "O1 Engineering run", i.e aren't generating new workunits anymore.

Instead we will continue the previously suspended "O2AS" run as a GW run. The current GPU App will not give much benefit in that setup, so "O2AS" will (for now) continue to be CPU-only.

If all goes as planned we will start with the "O1OD1 injection run" on GPUs.

BM
 
https://einsteinathome.org/content/parallella-raspberry-pi-fpga-all-stuff?page=96#comment-170961

koschi schrieb:
How is the performance of the T860, does it beat a fast x86 core? How much faster than one of the A72 cores of that board is it?
Runtime was about 1h 20min on my firefly-rk3399. Runtime on the A72-cores (@1.8Ghz) was around 2h on this Board.

Potential the runtime could be way better (<1h). But there are some things in the openCL-code that are not optimal for a system like this, with slow shared memory. The BRP-openCL-code makes heavy use of LUT's, which speed's up things on "real" GPU's with fast GDDR5X/HBM-Memory but hit's performance on slow memory systems. (The Firefly uses only DDR3-PC1333.) I've changed some things and was able to squeeze out runtimes slightly below 1h. But this increased the invalid-rate by a fraction. Even without this modifications the invalid-rate was high. Around 20%. I know what caused this but there was no (easy) way around it.

Anyway the mail-midgard-series (T-xxx) show's bad openCL-Performance due to it's weird architecture. Midgard-GPU's are vector-based, similar to NEON/SSE/AVX on the CPU-side. You have to rely on vectorisation of the openCL compiler. Vectorisation is not alway's possible. So openCL-code has to be written with a midgard-GPU in mind to get decent performance. Also the auto-vectorisation seem's to be the reason that caused my invalid's. Setting the auto-vectorisation to be more aggressive increased the invalid-rate.

And I wasn't able to create a app_info that enables Boinc to use GPU and CPU for the same App at the same time. -.- Sometimes I really hate Boinc ;).

Using only the GPU and with around 20% invalids, the RAC of this Board was slightly better than a RPI3 with my optimized-App. Around 1100 to 1200.



koschi schrieb:
I'll be receiving an Odroid N2 tomorrow, featuring 4 x A73 (1.8 GHz) and 2 x A53 (1.9GHz) and 4GB RAM. The Amlogic S922X SoC comes with a Mali G52, which on paper is faster than the T860. So all in all a promising package. Would be awesome if its GPU could also be used as well
I was able to grep a N2 from the first Batch :) But didn't test Boinc-performance, yet.

In general it's Bifrost-GPU(Gxx) should be way better for openCL-Task's as ARM dropped the vector-based approch :).


At the Moment, my N2 is dedicated to some Monitoring-Task's for my mini-ARM-Cluster.

You can take a look here: http://31.17.18.50/nagUI/

Development is in a really early stage. At the moment I'm working on some Boinc-related readouts. But this is only a small side-project, so things go slow as I don't put to much time into it.

N30DG, der auch schon die optimierten Anwendungen für 64bit Odroid C2 und Raspberry Pi3 erstellt hatte, hat den BRP code auf der Mali GPU seines Firefly Boards (mit RK3399) zum Laufen bekommen. Meines Wissens nach wurde damit erstmals BOINC auf der Mali GPU eines ARM Boards lauffähig gemacht. Riesige Gewinne sind sicher nicht zu erwarten, die T860 seines Firefly Boards erzeugt aber einen RAC der einen Raspberry Pi 3 leicht übertrifft. Einen A72 Kern des Firefly (2 x A72, 4 x A53) steckt die T860 aber in die Tasche. Auch sei die ältere T860 im Vergleich zum N2 eher langsam.

--- Update ---

Achja, ich hatte heute einige Engineering WUs (v0.07) auf der CPU, diese liefen in ~19000 Sekunden durch bei je 1000 Credits.
Das kann sich sehen lassen!
 
Ich denke mal ich lehne mich nicht zu weit aus dem Fenster, wenn ich behaupte das sompes 8 GPU cruncher demnächst die Führung unter den schnellsten Computern bei Einstein übernimmt:

https://einsteinathome.org/host/12776708/tasks/0/0

Von 370 Sekunden pro Task ausgehend, wären das 6.472.994 Credits pro Tag.
Die aktuelle #1 der Liste hat auch 8 Fiji, rechnet aber ~420s an den Tasks. Das müsste an sich für einen RAC von 5,7Mio reichen, aktuell ist er bei 4.2Mio.
 
Mehr Power! Auf das die Fetzen fliegen. *attacke*
Bei den späteren WUs ist die Laufzeit allerdings auf ca. 405s gestiegen, vermutlich weil die CPU WUs in der VM die Spitzen bei der CPU Last der GPU WUs abschneiden. Da gab es bei mir immer mal wieder Ausreisser bis 60/70% gesammt CPU Last bei 8 Kernen/Threads, meist lag sie aber irgendwo bei 45-55%.
Wenn Einstein bei Penta ran kommt dann könnte man der VM für die CPU WUs vielleicht noch 1-2 Kerne klauen um noch das letzte bischen aus den GPUs zu quetschen. :)
 
Zuletzt bearbeitet:
Kann mir einer sagen was die besten Einstellung für meine kleine Vega8 ist, wenn ich auf 3 CPU Kerne etwas anderes rechne?

--- Update ---

Irgendwie steigt der GPU Load nicht. Der Takt steigt nach oben aber mehr auch nicht*noahnung*
 
Wie ich in dem Penta Thread schonmal schrieb bevorzuge ich es bei gleichzeitig laufenden CPU und GPU WUs die CPU WUs in eine VM zu verbannen damit sie die GPU WU nicht verdrängen oder ihr die CPU Laufzeit wegfressen können. Bei der Leistungsklasse der Fiji GPU hatte ich die Erfahrung gemacht das dafür ca. 0,5-0,75 Zen Kerne oder 1-2 FX Kerne abgestellt werden sollten. Da die Vega 8 GPU ein gutes Stück langsamer ist sollte sie bei einem Zen Kern auch mit deutlich weniger CPU Laufzeit zurecht kommen.

Mir fehlt an der Stelle aber ein wenig die Erfahrung mit der Vega Architektur bei Einstein.
Aktuell lasse ich meinen Konsolero mit der auf relativ sparsam gedrosselten Vega64 (durchschnittlich 1,47 GHz) und dem Ryzen 1700 bei Einstein einfahren und da liegt die Kernauslastung rechnerisch bei ca. 35%. (2,1% CPU Auslastung bei 16 Threads)
Wenn das ca. 1:1 skaliert dann sollte die Vega 8 ca. 4-5% Kernauslastung benötigen, wenn dabei der CPU Takt deutlich runter geschraubt wird vielleicht auch 10%. Da könnte man sogar versuchen noch etwas anderes auf dem Kern laufen zu lassen und schauen wie sehr es die Laufzeit der GPU WU beeinflusst.
 
Zuletzt bearbeitet:
Meine 3 Kerne rechnen in einer VM yoyo und einen CPU Kern habe ich frei für Windows usw... Mir ging es um Einstellungen, die ich bei Einstein machen muss, damit die GPU auch wirklich Arbeitet. Aber die GPU Auslastung ist bei 0%.
 
Hast Du nur GPU-WUs zugelassen?
 
So ist es eingestellt!
 
Wie sieht es aus wenn die VM beendet wurde und nur das nachkte Windows auf die GPU zugreifen kann? Nicht dass die GPU durchgereicht wird und deshalb keine Arbeit annimmt.
Ist der GPU Treiber korrekt installiert? Wie sieht es nach einem Neustart aus? Nicht das irgendetwas installiert wurde das nun die GPU blockiert.
Ist im Boinc Manager bei den Berechnungseinstellungen der Punkt "Benutzung des Grafik Prozessors unterbrechen, während Rechner in Benutzung ist." deaktiviert? Wenn nein wundert es mich nicht das die GPU WU nicht los läuft solange du am Rechner aktiv bist. ;)
 
Also Rechnen tut er schon. BM zeigt dies an, aber mit GPU-Z sehe ich keinen GPU Load.
 
Projekt heute hinzugefügt? Wenn nicht vielleicht mal komplett löschen und wieder hinzufügen?
 
Hinzugefügt, letzte Woche, als es mit dem Penta losging. Also sind es wohl die neusten apps heruntergeladen. Und Treiber hat sich nicht geändert.
 
Einfach mal mit einem anderen programm nachschauen, nicht dass es lediglich daran liegt das GPU-Z es nicht korrekt auslesen kann.
 
Hm. also HWInfo sagt mir das ich einen GPU Comuting von ca. 93% habe! Also wird wohl GPU-Z da ein Problem haben.
 
Na dann mal auf zum loscrunchen. ;D
 
Bunker ist full ;)
 
Was brauch ich denn mindestens, um die RX480 unter Linux (openSUSE Leap) für Einstein rechnen zu lassen? Brauche ich den AMDGPU-Pro, oder langt OpenCL, oder ... *noahnung*

Gruß,
Ritschie
 
Das openCL aus dem amdgpu-pro ist bei Einstein die performanteste OpenCL Implementierung. Wird nur auf Leap knifflig, da nicht offiziell unterstützt. Ich hatte mir für Ubuntu 19.04 die libraries aus dem Treiber für 18.04 rausgepopelt, inspiriert von einem Script für Arch Linux. Vielleicht klappt das ja auch bei Suse?

--- Update ---

Den AMDGPU Treiber selbst bringt ja der Kernel schon mit du brauchst nur eine funktionierende openCL Implementierung.
 
Den AMDGPU Treiber selbst bringt ja der Kernel schon mit
Den AMDGPU ohne PRO, reicht der denn?

du brauchst nur eine funktionierende openCL Implementierung
Mir wird über die Paketverwaltung angeboten:
- Mesa-libOpenCL oder
- libopencl-amdgpu-pro

Da ich amdgpu-pro nicht installiert habe, würde ich auf den Mesa tippen *noahnung*

Für "knifflig, da nicht offiziell unterstützt" und "rauspopeln" bin ich def. zu dumm und es fehlt mir die Zeit (bin nur noch heute am PC). Von daher wäre ich schon überglücklich, wenn ich die RX überhaupt zum Laufen kriege.

Gruß,
Ritschie
 
Zuletzt bearbeitet:
Ja versuch mal das letztere, vielleicht hat ja jemand Analog zu Arch für Suse was gehakt. Oder mal diesem link folgen:
https://en.opensuse.org/SDB:AMDGPU-PRO

Bin grad aufm Telefon im ICE unterwegs, sonst könnte ich dir mal raussuchen welche files aus dem Treiber du brauchst.
 
Zurück
Oben Unten