Odroid
- Ersteller Raspo
- Erstellt am
herby44
Vice Admiral Special
Moin
Deine Vermutung traf den ARMen auf den Kopf jetzt läufts, ich hatte vorher die minimal version installiert da liessen sich beide libs nicht installieren E: Unable to locate package libsfstdc++6:armhf
E: Couldn't find any package by regex 'libsfstdc++6' dabei währe sie für den Headless betrieb gut geeignet.
Deine Vermutung traf den ARMen auf den Kopf jetzt läufts, ich hatte vorher die minimal version installiert da liessen sich beide libs nicht installieren E: Unable to locate package libsfstdc++6:armhf
E: Couldn't find any package by regex 'libsfstdc++6' dabei währe sie für den Headless betrieb gut geeignet.
koschi
Grand Admiral Special
Ich habe auch einen C2 mit Ubuntu minimal, ich musste jedoch erst die armhf Architektur hinzufügen, damit er die Bibliothek installiert:
Code:
dpkg --add-architecture armhf
apt updateDanke an koschi, LordNord, olsen_gg für die Beantwortung der Fragen.
@Herby44
Mit der Ubuntu Minimal Installation funktioniert es auch du musst vorher folgendes tuen.
dpkg --add-architecture armhf
apt-get update
apt-get install libstdc++6:armhf
Eine Fehlerbeschreibung für die entsprechende WU findet man, wenn man den Link "Task click for details" anklickt.
Es ist unter Stderr output protokolliert.
@Herby44
Mit der Ubuntu Minimal Installation funktioniert es auch du musst vorher folgendes tuen.
dpkg --add-architecture armhf
apt-get update
apt-get install libstdc++6:armhf
Eine Fehlerbeschreibung für die entsprechende WU findet man, wenn man den Link "Task click for details" anklickt.
Es ist unter Stderr output protokolliert.
Zuletzt bearbeitet:
MagicEye04
Grand Admiral Special
Speicher übertakten? Da kann ich mir generell immer nicht vorstellen, dass es was bringt.
Bei extrem speicherhungrigen Projekten kann man es vielleicht überhaupt messen, aber ansonsten laufen doch kaum groß Speicherzugriffe ab.
Bei extrem speicherhungrigen Projekten kann man es vielleicht überhaupt messen, aber ansonsten laufen doch kaum groß Speicherzugriffe ab.
herby44
Vice Admiral Special
Hallo
Danke Leute jetzt sieht es garnicht mal so schwierig aus, eine Architektur hinzufügen da währe ich von alleine nie drauf gekommen.
Danke Leute jetzt sieht es garnicht mal so schwierig aus, eine Architektur hinzufügen da währe ich von alleine nie drauf gekommen.
Olle Kalesche
Admiral Special
MagicEye04 schrieb:
Ich versuch es mal zu erklären.
Bei aktuell käuflichen APUs wird immer gesagt, der Speicher sei zu lahm, um die iGPU ordentlich in Schwung zu bringen (Geschwindigkeits-Engpaß des Speichers).
Bei den bald käuflich erwerbbaren AMD-APUs soll das bald anders werden, weil erstens kommt DDR4 zum Einsatz
und zweitens sind diese Speicher höher getaktet, dann sollen die iGPUs passabel schnell sein (kein Engpaß mehr).
Beim C2 läuft die CPU üblicherweise mit ca. 1,5GHz. Den takte ich jetzt höher, nämlich mit 1,75GHz.
Sagen wir effektiv ist der C2 jetzt Pi*Daumen 10% schneller.
Wenn ich dann den Speicher vom C2 um 10% schneller takten kann, ist der Speicherzugriff besser,
d.h. der C2 wird nochmals schneller (gehen wir der Einfachheit halber von 2,5% Gewinn aus).
Wenn zuletzt mit einem neuen Kernel auch noch der L2-Cache aktiviert werden kann, kommen evtl. noch mal 7,5%
Leistungszuwachs hinzu.
D.h. CPU schneller takten, Speicher höher takten und dann noch den vorhandenen L2-Cache nutzen können, bringt
vielleicht insgesamt 15-20% Leistungszuwachs im Vergleich zum "Standard-C2"
(die %-Angaben sind vermutlich nicht real, aber zeigen, wo es lang geht).
Mit dem zukünftigen neuen Kernel wird möglicherweise auch noch die iGPU (Mali) des C2 besser unterstützt,
das könnte (Konditional !) bedeuten, daß die iGPU des C2 auch für Boinc nutzbar wird (erst mal reine Theorie -
ergibt ggf. nochmals x-% Leistungszuwachs ?).
Das wäre doch nicht schlecht, oder ?
@herby44
Na, das hat doch geklappt !
MagicEye04
Grand Admiral Special
Alles schön und gut und richtig - aber der Knackpunkt ist, dass Boinc in der Regel fast gar nichts mit dem RAM macht.
Bei APUs und vor allem beim Spielen werden ja für jedes zu berechnende Einzelbild immer die hochdetailierten Texturen im Speicher rein und rausgeschubst, da wandern Tonnenweise Gigabytes durch die Leitung. In so einem Fall profitiert man natürlich von mehr Bandbreite.
Meinen FX-Rechner hatte ich jahrelang mit mit 1333er Speichertakt betrieben, weil ich zu faul war, die Timings für 1600 zu ermitteln (mit Auto wollte er nicht stabil laufen).
Dieses Jahr bin ich endlich mal dazu gekommen. Und trotz dieses eigentlich sehr satten Zuwachses an Speicherbandbreite haben sich die Berechnungszeiten überhaupt nicht groß geändert, das ging im Rauschen unter. Weil eben Boinc nicht tonnenweise Daten in den Speicher rein und raus schiebt.
Darum ist es ja in der Regel auch egal, wenn man bei GPU-Projekten die Karte nur in einen PCIe1x-Slot steckt, wo massiv Bandbreite fehlen würde und kein Spiel mehr vernünftig läuft.
Wenn mal irgendwann der GPU-Teil des C2 benutzt werden kann, sieht das vielleicht anders aus.
Bei APUs und vor allem beim Spielen werden ja für jedes zu berechnende Einzelbild immer die hochdetailierten Texturen im Speicher rein und rausgeschubst, da wandern Tonnenweise Gigabytes durch die Leitung. In so einem Fall profitiert man natürlich von mehr Bandbreite.
Meinen FX-Rechner hatte ich jahrelang mit mit 1333er Speichertakt betrieben, weil ich zu faul war, die Timings für 1600 zu ermitteln (mit Auto wollte er nicht stabil laufen).
Dieses Jahr bin ich endlich mal dazu gekommen. Und trotz dieses eigentlich sehr satten Zuwachses an Speicherbandbreite haben sich die Berechnungszeiten überhaupt nicht groß geändert, das ging im Rauschen unter. Weil eben Boinc nicht tonnenweise Daten in den Speicher rein und raus schiebt.
Darum ist es ja in der Regel auch egal, wenn man bei GPU-Projekten die Karte nur in einen PCIe1x-Slot steckt, wo massiv Bandbreite fehlen würde und kein Spiel mehr vernünftig läuft.
Wenn mal irgendwann der GPU-Teil des C2 benutzt werden kann, sieht das vielleicht anders aus.
Olle Kalesche
Admiral Special
MagicEye04 schrieb:
Ich denke, das ist nicht ganz richtig. Der RAM wird schon sehr heftig im Boinc genutzt.
Ich kenne die Programme nicht, aber ich stell mir vor die WU wird vermutlich nur einmal eingelesen und dann
nach den im Programm vorgegebenen mathematischen Regeln analysiert, d.h. die im RAM vorliegenden Daten der WU
werden häppchenweise nach und nach überprüft.
Das ist ein ständiges Weiter-Lesen der Daten der WU im RAM bis die im RAM vorhandene WU "durchgekaut" ist.
Zwischenzeitlich wird auch mal ein Syncpoint geschrieben, aber hefigen In- und Output ist bei den meisten
Projekten nicht angesagt.
Da ist die reine Geschwindigkeit auf den RAM zugreifen zu können schon maßgeblich, denke ich.
Daß ein Aufrüsten von 1333er auf 1600er Speicher nicht viel für "Normale" Programme mit viel I/O bringt
habe ich auch schon erfahren.
Wenn die iGPU genutzt werden kann, dann laufen vermutlich OpenCL-Berechnungen darüber.
Das geht schneller als mit der CPU.
MagicEye04
Grand Admiral Special
Das ist aber schon ein gewaltiger Unterschied, ob so eine WU im RAM stundenlang in kleine Häppchen unterteilt und analysiert wird oder ob fast der komplette Speicherinhalt innerhalb von Sekundenbruchteilen gefüllt, minimal geändert und weitergeschoben wird zur GPU.
Da helfen wohl nur vorher/nachher-Vergleiche.
Bei mir war es wie gesagt von 1333 auf 1600 nicht wirklich messbar (ich bezog mich auf Boinc, was anderes läuft hier gar nicht).
Da helfen wohl nur vorher/nachher-Vergleiche.
Bei mir war es wie gesagt von 1333 auf 1600 nicht wirklich messbar (ich bezog mich auf Boinc, was anderes läuft hier gar nicht).
Olle Kalesche
Admiral Special
Ja, viel bringt eine Erhöhung des RAM-Taktes vermutlich nicht, deshalb gab ich in meinem Beispiel zuvor auch an,
daß das vielleicht 2,5% ausmacht. Den L2-Cache nutzen können bringt wahrscheinlich viel mehr.
Wenn ich mich recht erinnere, hatte jemand im Zen-Thread einmal geäußert, ohne L1-(L2-)Cache ist ein PC so schnell
wie ein Taschenrechner. Deshalb erhoffe ich mir merklichen Geschwindigkeitszuwachs,
wenn der L2-Cache zukünftig genutzt werden kann. Bei Nutzung der iGPU ist vielleicht auch noch ein Zuwachs drin.
daß das vielleicht 2,5% ausmacht. Den L2-Cache nutzen können bringt wahrscheinlich viel mehr.
Wenn ich mich recht erinnere, hatte jemand im Zen-Thread einmal geäußert, ohne L1-(L2-)Cache ist ein PC so schnell
wie ein Taschenrechner. Deshalb erhoffe ich mir merklichen Geschwindigkeitszuwachs,
wenn der L2-Cache zukünftig genutzt werden kann. Bei Nutzung der iGPU ist vielleicht auch noch ein Zuwachs drin.
koschi
Grand Admiral Special
Hier nochmal der Artikel, über den ich überhaupt erst dazu kam die Performance des C2 auf den verschiedenen Taktstufen zu messen:
http://wiki.ant-computing.com/Choosing_a_processor_for_a_build_farm
Der Autor übersetzt regelmäßig Code und misst die Performance der Systeme über die Laufzeit des Kompiliervorgangs oder auch in LoC/s (lines of code per second).
Ich habe mal den C2, den NanoPC-T3 sowie den MiQi herauskopiert. NanoPC schlägt C2, MiQi schlägt NanoPC. Soweit so bekannt.
Interessant sind jedoch seine Messungen des MiQi mit verschiedenen RAM Taktraten. Mit nur 200MHz DDR3 ist die Performance quasi unterirdisch. Mit 528MHz fehlt nicht mehr viel zum 8-Kerner NanoPC T3. Mit nochmal 264MHz mehr legt der MiQi noch 5% drauf und überholt den T3. Ich denke oberhalb von 792MHz wird da dann auch nicht mehr viel zu holen sein, es steht schlicht genug Bandbreite zur Verfügung.
Inwieweit der C2 nun schon über genügend Bandbreite verfügt, ich vermag es nicht zu sagen. Da hilft nur testen...
Sicher profitieren die Projekte auch unterschiedlich stark von Bandbreitenerhöhungen.
http://wiki.ant-computing.com/Choosing_a_processor_for_a_build_farm
Der Autor übersetzt regelmäßig Code und misst die Performance der Systeme über die Laufzeit des Kompiliervorgangs oder auch in LoC/s (lines of code per second).
Ich habe mal den C2, den NanoPC-T3 sowie den MiQi herauskopiert. NanoPC schlägt C2, MiQi schlägt NanoPC. Soweit so bekannt.
Interessant sind jedoch seine Messungen des MiQi mit verschiedenen RAM Taktraten. Mit nur 200MHz DDR3 ist die Performance quasi unterirdisch. Mit 528MHz fehlt nicht mehr viel zum 8-Kerner NanoPC T3. Mit nochmal 264MHz mehr legt der MiQi noch 5% drauf und überholt den T3. Ich denke oberhalb von 792MHz wird da dann auch nicht mehr viel zu holen sein, es steht schlicht genug Bandbreite zur Verfügung.
Code:
Date ? Machine ? Processes ? Time (seconds) ? LoC/s LoC/s/GHz/core ? Observations
2016/03/12 ODROID-C2 4 27.96s 16410 2671 ... respectively for 1, 2 and 4 processes.
2016/05/21 NanoPC-T3 8 21.8s 21049 1879
2016/05/21 NanoPC-T3 4 29.6s 15502 2768
2016/07/26 mqmaker MiQi 4 45.2s 10152 1578 very slow by default, DDR3 runs at only 200 MHz!
2016/07/26 mqmaker MiQi 4 22.6s 20304 3157 DDR3 at 528 MHz (echo p > /dev/video_pstate)
2016/07/27 mqmaker MiQi 4 21.4s 21442 3334 DDR3 at 792 MHz
2016/07/27 mqmaker MiQi 4 19.7s 23292 3235 CPU at 1800 MHz, DDR3 at 792 MHz
2016/07/27 mqmaker MiQi 4 18.1s 25352 3144 CPU at 2016 MHz, DDR3 at 792 MHzInwieweit der C2 nun schon über genügend Bandbreite verfügt, ich vermag es nicht zu sagen. Da hilft nur testen...
Sicher profitieren die Projekte auch unterschiedlich stark von Bandbreitenerhöhungen.
olsen_gg
Grand Admiral Special
Irgendwie basiert es bis dahin alles auf Vermutungen.
Ich würde für gesichert halten, dass der C2 mit jeder Takterhöhung, auch beim RAM, mehr Strom braucht - und dass man aufpassen muss, dass alles noch stabil und kühl bleibt.
Unter Umständen ist es dann einfacher, einen C2 mehr einzusetzen.
Das ist dann vom Strom her (ebenfalls vermutlich) dasselbe und ich weiß, dass alles stabil läuft.
Außerdem habe ich sofort 4 Kerne mehr
.
Ich würde für gesichert halten, dass der C2 mit jeder Takterhöhung, auch beim RAM, mehr Strom braucht - und dass man aufpassen muss, dass alles noch stabil und kühl bleibt.
Unter Umständen ist es dann einfacher, einen C2 mehr einzusetzen.
Das ist dann vom Strom her (ebenfalls vermutlich) dasselbe und ich weiß, dass alles stabil läuft.
Außerdem habe ich sofort 4 Kerne mehr
.cyrusNGC_224
Grand Admiral Special
Ich hatte auf dem Desktop ebenfalls mal Speichertakt variiert und dann die Boinc Ergebnisse verglichen. Der Unterschied ist wie gesagt innerhalb der Messtoleranz.
Beim C2 müsste man das tatsächlich mal testen. Aber wer sagt, dass da der L2 Cache deaktiviert sein soll? Das kann ich mir nicht vorstellen, dann müsste der kriechen. Und außerdem wird CPU intern verwaltet, wie die Caches genutzt werden.
Beim C2 müsste man das tatsächlich mal testen. Aber wer sagt, dass da der L2 Cache deaktiviert sein soll? Das kann ich mir nicht vorstellen, dann müsste der kriechen. Und außerdem wird CPU intern verwaltet, wie die Caches genutzt werden.
Olle Kalesche
Admiral Special
@koschi
Das ist ein interessanter Artikel. Vermutlich muß ich mir den noch mehrmals durchlesen, bis ich alles verstanden habe.
Mir ist auf jeden Fall aufgefallen, daß bei manchen Boards viele CPUs vorhanden sind, aber viel zu wenig RAM.
@olsen_gg
Sicherlich benötigt jede Erhöhung des Taktes bei der CPU, iGPU oder beim RAM mehr Strom,
aber wenn es sich "im Rahmen" hält, geht es vielleicht.
Ansonsten hat "mein Lieferant" gerade ein Odroid-C2-Bundle im Angebot - ich denke schon wieder darüber nach nachzurüsten ...
@cyrusNGC_224
Ich weiß wozu Lx-Caches gut sind, aber wie und von wem Caches verwaltet werden (HW, SW oder beides),
da kenne ich mich nicht aus.
Ob der L2-Cache im C2 aktuell genutzt wird weiß ich auch nicht, aber im Odroid-Forum
(ich vermute, Er weiß wovon Er redet) äußert sich z.B. "mlinuxguy" » Wed Sep 07, 2016 4:22 am :
Es klingt für mich, als ob der L2-Cache entweder nicht verwendet wird oder nur unzureichend unterstützt wird, siehe nochmals
" ... it appears to actually get a working L2 cache we need entries like this in the appropriate DTS file: meson-gxbb.dtsi ."
Für mich ist das ein eindeutiger Hinweis, da fehlt was oder ist noch nicht in Ordnung.
Also mit dem L2-Cache liegt es wohl irgendwie noch im Argen beim C2 ...
Das ist ein interessanter Artikel. Vermutlich muß ich mir den noch mehrmals durchlesen, bis ich alles verstanden habe.
Mir ist auf jeden Fall aufgefallen, daß bei manchen Boards viele CPUs vorhanden sind, aber viel zu wenig RAM.
@olsen_gg
olsen_gg schrieb:
Sicherlich benötigt jede Erhöhung des Taktes bei der CPU, iGPU oder beim RAM mehr Strom,
aber wenn es sich "im Rahmen" hält, geht es vielleicht.
Ansonsten hat "mein Lieferant" gerade ein Odroid-C2-Bundle im Angebot - ich denke schon wieder darüber nach nachzurüsten ...
@cyrusNGC_224
Ich weiß wozu Lx-Caches gut sind, aber wie und von wem Caches verwaltet werden (HW, SW oder beides),
da kenne ich mich nicht aus.
Ob der L2-Cache im C2 aktuell genutzt wird weiß ich auch nicht, aber im Odroid-Forum
(ich vermute, Er weiß wovon Er redet) äußert sich z.B. "mlinuxguy" » Wed Sep 07, 2016 4:22 am :
mlinuxguy (Odroid-Forum) schrieb:
Es klingt für mich, als ob der L2-Cache entweder nicht verwendet wird oder nur unzureichend unterstützt wird, siehe nochmals
" ... it appears to actually get a working L2 cache we need entries like this in the appropriate DTS file: meson-gxbb.dtsi ."
Für mich ist das ein eindeutiger Hinweis, da fehlt was oder ist noch nicht in Ordnung.
Also mit dem L2-Cache liegt es wohl irgendwie noch im Argen beim C2 ...
herby44
Vice Admiral Special
Moin alle zusammen
nachdem ich Gestern einen meiner C2 neugestartet hatte und mit Boinctui gleich darauf zugriff viel mir auf das er bei jedem Neustart einen Benchmark durchfühen will
und ihn offensichtlich abbrach > (error) CPU Benchmarks timed out, using default values < das habe ich bei allen sieben C2 festgestellt, sie rechnen einfach weiter
ich habe mal einen Benchkark von Hand gestartet und der lief durch, auch im Boincmanager kannman es unter Wekzeuge/Meldungen lesen, ich habe keine Ahnung warum sie das machen.
Gruß herby44
nachdem ich Gestern einen meiner C2 neugestartet hatte und mit Boinctui gleich darauf zugriff viel mir auf das er bei jedem Neustart einen Benchmark durchfühen will
und ihn offensichtlich abbrach > (error) CPU Benchmarks timed out, using default values < das habe ich bei allen sieben C2 festgestellt, sie rechnen einfach weiter
ich habe mal einen Benchkark von Hand gestartet und der lief durch, auch im Boincmanager kannman es unter Wekzeuge/Meldungen lesen, ich habe keine Ahnung warum sie das machen.
Gruß herby44
Das ist normal. Bei den C2 dauert es beim Neustart etwas länger bis das richtige Datum/Uhrzeit vom Server geholt wird.Moin alle zusammen
nachdem ich Gestern einen meiner C2 neugestartet hatte und mit Boinctui gleich darauf zugriff viel mir auf das er bei jedem Neustart einen Benchmark durchfühen will
und ihn offensichtlich abbrach > (error) CPU Benchmarks timed out, using default values < das habe ich bei allen sieben C2 festgestellt, sie rechnen einfach weiter
ich habe mal einen Benchkark von Hand gestartet und der lief durch, auch im Boincmanager kannman es unter Wekzeuge/Meldungen lesen, ich habe keine Ahnung warum sie das machen.
Gruß herby44
Deshalb bricht der BM den Benchmark ab und nimmt alte Werte.
koschi
Grand Admiral Special
Code:
root@odroidc2-8:~/einstein_bench# time ./apps/einsteinbinary_BRP4_0.13_AARCH64-unknown-linux-gnu_1 -i testwu/p2030.20151015.G187.41-00.88.N.b2s0g0.00000_1099.bin4 -t testwu/stochastic_full.bank -l testwu/p2030.20151015.G187.41-00.88.N.b2s0g0.00000.zap -o results.cand0 -c nocheckpoint.cpt -A 0.08 -P 3.0 -f 400.0 -W -z
Application startup - thank you for supporting Einstein@Home!
real 195m20.743s
user 195m20.300s
sys 0m2.220s
root@odroidc2-8:~/einstein_bench# time ./apps/einsteinbinary_BRP4_0.13_AARCH64-unknown-linux-gnu_1 -i testwu/p2030.20151015.G187.41-00.88.N.b2s0g0.00000_1099.bin4 -t testwu/stochastic_full.bank -l testwu/p2030.20151015.G187.41-00.88.N.b2s0g0.00000.zap -o results.cand0 -c nocheckpoint.cpt -A 0.08 -P 3.0 -f 400.0 -W -z
Application startup - thank you for supporting Einstein@Home!
real 181m45.700s
user 181m38.650s
sys 0m2.320s2x die gleiche Einstein-WU auf einem C2 im Leerlauf getestet. Der erste Durchlauf mit RAM @912MHz, der zweite @1104MHz. +21% RAM-Takt resultieren in einer Laufzeitverkürzung von 7%. Meiner Meinung nach nicht zu verachten.
Einen Phoronixdurchlauf gegen gestrige Werte aus dem BOINC auf ARM Thread reiche ich nach...
--- Update ---
Bei den non-BOINC Benchmarks zeigen sich nur bedingt Verbesserungen, 2% beim Audio Encoding, ein saftiger Sprung im Himeno Benchmark:
http://openbenchmarking.org/result/1609207-KH-1609199KH65
Laut Eigenaussage der Entwickler profitiert letzterer stark von Speicherbandbreite:
http://accc.riken.jp/en/supercom/himenobmt/
MagicEye04
Grand Admiral Special
Wow, hätte ich nicht gedacht.
Liegt das womöglich daran, dass die ARMCPU für Berechnungen an sich ja eher schwach ist und selbst nicht viel Cache hat und somit viel auf den RAM zugreifen muss?
Liegt das womöglich daran, dass die ARMCPU für Berechnungen an sich ja eher schwach ist und selbst nicht viel Cache hat und somit viel auf den RAM zugreifen muss?
cyrusNGC_224
Grand Admiral Special
Wäre wohl eine Erklärung. Eigentlich müsste aber auch der Verbrauch etwas höher gehen.
koschi
Grand Admiral Special
Soweit ich das verstanden habe, ist das Übertaktung ohne Spannungsanhebung, der zusätzliche Verbrauch sollte sich im Rahmen halten.
Habe jetzt sicher schon 12 Einheiten Einstein optimiert @ 1.68GHz & 1104 in ~12500 Sekunden fertig bekommen. Ich denke gerade wenn 4 Einheiten laufen macht sich die zusätzliche Bandbreite bemerkbar (womöglich signifikanter als bei obigen Resultaten mit nur einer WU).
Aktuell teste ich noch 4x Einstein @ 1.75 GHz (#6 scheint es zu können) gegen gleich 1.75GHz & 1104MHz RAM, dann haben wir mal einen Vergleich mit 4 WUs.
edit:
Odroid C2 1750MHz CPU & 912MHz RAM
root@odroidc2-6:~/einstein_bench# cat -vn einsteinbinary_BRP4_0.13_AARCH64-unknown-linux-gnu_*/boinc_EinsteinRadio_0 | grep cpu_time
11 <cpu_time>13200.280</cpu_time>
32 <cpu_time>13112.250</cpu_time>
53 <cpu_time>13187.390</cpu_time>
74 <cpu_time>13143.950</cpu_time>
Odroid C2 1750MHz CPU & 1104MHz
root@odroidc2-6:~/einstein_bench# cat -vn einsteinbinary_BRP4_0.13_AARCH64-unknown-linux-gnu_*/boinc_EinsteinRadio_0 | grep cpu_time
11 <cpu_time>12073.400</cpu_time>
32 <cpu_time>12002.650</cpu_time>
53 <cpu_time>12032.550</cpu_time>
74 <cpu_time>12002.220</cpu_time>
Bei paralleler Bearbeitung von 4 WUs reduziert sich die Laufzeit bei RAM Übertaktung sogar um ~8.5%.
Es werden sicher nicht alle Projekte gleichermaßen profitieren. Für Einstein kann man das aber mal mitnehmen. 12000s ist schon top, ein RPi3 braucht ca. 20k Sekunden mit optimierter app...
edit:
Hardkernel stellt ein Skript zur Verfügung um die RAM Übertaktung durchzuführen:
http://odroid.com/dokuwiki/doku.php?id=en:c2_adjust_ddrclk
Habe jetzt sicher schon 12 Einheiten Einstein optimiert @ 1.68GHz & 1104 in ~12500 Sekunden fertig bekommen. Ich denke gerade wenn 4 Einheiten laufen macht sich die zusätzliche Bandbreite bemerkbar (womöglich signifikanter als bei obigen Resultaten mit nur einer WU).
Aktuell teste ich noch 4x Einstein @ 1.75 GHz (#6 scheint es zu können) gegen gleich 1.75GHz & 1104MHz RAM, dann haben wir mal einen Vergleich mit 4 WUs.
edit:
Odroid C2 1750MHz CPU & 912MHz RAM
root@odroidc2-6:~/einstein_bench# cat -vn einsteinbinary_BRP4_0.13_AARCH64-unknown-linux-gnu_*/boinc_EinsteinRadio_0 | grep cpu_time
11 <cpu_time>13200.280</cpu_time>
32 <cpu_time>13112.250</cpu_time>
53 <cpu_time>13187.390</cpu_time>
74 <cpu_time>13143.950</cpu_time>
Odroid C2 1750MHz CPU & 1104MHz
root@odroidc2-6:~/einstein_bench# cat -vn einsteinbinary_BRP4_0.13_AARCH64-unknown-linux-gnu_*/boinc_EinsteinRadio_0 | grep cpu_time
11 <cpu_time>12073.400</cpu_time>
32 <cpu_time>12002.650</cpu_time>
53 <cpu_time>12032.550</cpu_time>
74 <cpu_time>12002.220</cpu_time>
Bei paralleler Bearbeitung von 4 WUs reduziert sich die Laufzeit bei RAM Übertaktung sogar um ~8.5%.
Es werden sicher nicht alle Projekte gleichermaßen profitieren. Für Einstein kann man das aber mal mitnehmen. 12000s ist schon top, ein RPi3 braucht ca. 20k Sekunden mit optimierter app...
edit:
Hardkernel stellt ein Skript zur Verfügung um die RAM Übertaktung durchzuführen:
http://odroid.com/dokuwiki/doku.php?id=en:c2_adjust_ddrclk
Zuletzt bearbeitet:
Olle Kalesche
Admiral Special
@koschi
Sehr gute Informationen von Dir, danke !
Gerade habe ich gelesen, HK hat ein script zum Einstellen der RAM Übertaktung zur Verfügung gestellt.
Punkt 1. wget "download c2_update_ddrclk.sh to your root filesystem" erledigt (ist damit nach /root gemeint ?)
und 2. chmod habe ich mit dem superuser ausgeführt.
Wenn ich bis hierher alles richtig gemacht habe, dann könnte ich jetzt den Update ausführen und rebooten.
Wenn alles klar geht - wunderbar, aber wenn doch Probleme auftreten, was dann ?
Muß ich dann versuchen ein Update mit dem script auf 912MHz zum Zurücksetzen auszuführen
oder läuft im schlimmsten Fall gar nichts mehr ?
Sehr gute Informationen von Dir, danke !
Gerade habe ich gelesen, HK hat ein script zum Einstellen der RAM Übertaktung zur Verfügung gestellt.
Punkt 1. wget "download c2_update_ddrclk.sh to your root filesystem" erledigt (ist damit nach /root gemeint ?)
und 2. chmod habe ich mit dem superuser ausgeführt.
Wenn ich bis hierher alles richtig gemacht habe, dann könnte ich jetzt den Update ausführen und rebooten.
Wenn alles klar geht - wunderbar, aber wenn doch Probleme auftreten, was dann ?
Muß ich dann versuchen ein Update mit dem script auf 912MHz zum Zurücksetzen auszuführen
oder läuft im schlimmsten Fall gar nichts mehr ?
koschi
Grand Admiral Special
Ich hab das bis dato 3 mal händisch gemacht, ohne Probleme. Effektiv sind es ja nur die 2 dd Befehle mit dem passenden bl1.bin*. Da kann an sich wenig schief gehen. Die bl1.bin Dateien zieht das Skript jeweils neu vom Server (werden in /tmp abgelegt). Die sind nur ~50kB groß, damit erübrigt sich die Suche nach den Dateien, richtiges Verzeichnis, etc...
Sollte also auch egal sein von welchem Verzeichnis aus du das aufrufst. Root file system bezieht sich hier mMn. lediglich auf dein C2 Image, das Skript nicht in einem Share abzulegen oder ähnlichem...
Zurücksetzen geht dann analog, ./c2_update_ddrclk.sh 912
Inwieweit du die Möglichkeit hast dein System zu zerschießen, ich denke die ist gering. Kommt der RAM nicht mit den 1104MHz klar, wird es womöglich instabil, WUs brechen ab oder werden nicht validiert. Dann würde ich nach einem Absturz zuerst BOINC anhalten (Last reduzieren), dann das Skript ansetzen... Solange du da an den dd Parametern count, skip, seek usw nicht drehst, wird das schon den richtigen Bereich im Bootloader treffen
Sollte also auch egal sein von welchem Verzeichnis aus du das aufrufst. Root file system bezieht sich hier mMn. lediglich auf dein C2 Image, das Skript nicht in einem Share abzulegen oder ähnlichem...
Zurücksetzen geht dann analog, ./c2_update_ddrclk.sh 912
Inwieweit du die Möglichkeit hast dein System zu zerschießen, ich denke die ist gering. Kommt der RAM nicht mit den 1104MHz klar, wird es womöglich instabil, WUs brechen ab oder werden nicht validiert. Dann würde ich nach einem Absturz zuerst BOINC anhalten (Last reduzieren), dann das Skript ansetzen... Solange du da an den dd Parametern count, skip, seek usw nicht drehst, wird das schon den richtigen Bereich im Bootloader treffen
Zuletzt bearbeitet:
Olle Kalesche
Admiral Special
OK, ich werde es auf dem erstgelieferten C2 ausführen, sobald die Einsteine fertig sind in 3h,
den Seti halte ich an.
Du hattest Deine Tests mit Einsteinen ausgeführt.
Ich denke es wäre eine gute Idee, wenn ich das dann auch erst einmal mit Einsteinen ausprobiere.
Einen Einstein oder gleich 4 Einsteine ?
den Seti halte ich an.
Du hattest Deine Tests mit Einsteinen ausgeführt.
Ich denke es wäre eine gute Idee, wenn ich das dann auch erst einmal mit Einsteinen ausprobiere.
Einen Einstein oder gleich 4 Einsteine ?
koschi
Grand Admiral Special
Ich würde gleich mit 4 Einsteinen einsteigen, das bildet die Realität am besten ab
Ich hab dir mal meinen Einstein "bench" gepackt, darin 3 kleine Skripte und eine Referenz-WU. Damit kann man verschiedene apps gegeneinander antreten lassen, oder halt auch 4 mal die gleiche starten. Hat den Vorteil, dass du dir bei Problemen keine aktiven WUs schrottest...
http://kerbodyne.com/einstein/einstein_bench.tar.gz
Herunterladen und entpacken, dann in das Verzeichnis einstein_bench wechseln. Das Skript runall.sh startet dann 4 WUs (bzw. soviele Läufe wie apps im Verzeichnis apps sind. Anschließend zeigt es minütlich den Fortschritt an. Wenn du überall bei 1.00 bist, kannst du es abbrechen.
Um die finale Laufzeit pro Task zu ermitteln, kannst du anschließend folgendes Kommando absetzen:
cat -vn einsteinbinary_BRP4_0.13_AARCH64-unknown-linux-gnu_*/boinc_EinsteinRadio_0 | grep cpu_time
Um weitere Durchläufe zu starten einfach das Skript cleanup.sh aufrufen, es löscht die alten "Slots"...
edit:
du brauchst noch das Paket "time", einfach über apt installieren
Ich hab dir mal meinen Einstein "bench" gepackt, darin 3 kleine Skripte und eine Referenz-WU. Damit kann man verschiedene apps gegeneinander antreten lassen, oder halt auch 4 mal die gleiche starten. Hat den Vorteil, dass du dir bei Problemen keine aktiven WUs schrottest...
http://kerbodyne.com/einstein/einstein_bench.tar.gz
Herunterladen und entpacken, dann in das Verzeichnis einstein_bench wechseln. Das Skript runall.sh startet dann 4 WUs (bzw. soviele Läufe wie apps im Verzeichnis apps sind. Anschließend zeigt es minütlich den Fortschritt an. Wenn du überall bei 1.00 bist, kannst du es abbrechen.
Um die finale Laufzeit pro Task zu ermitteln, kannst du anschließend folgendes Kommando absetzen:
cat -vn einsteinbinary_BRP4_0.13_AARCH64-unknown-linux-gnu_*/boinc_EinsteinRadio_0 | grep cpu_time
Um weitere Durchläufe zu starten einfach das Skript cleanup.sh aufrufen, es löscht die alten "Slots"...
edit:
du brauchst noch das Paket "time", einfach über apt installieren
Zuletzt bearbeitet:
Olle Kalesche
Admiral Special
Mausalarm !
Der 18 Jahre alte Kater hat ne Maus angeschleppt. Jetzt muß ich erst mal nachsehen, ob die noch rennt ...
--- Update ---
OK ! Maus entsorgt und dem Kater ein Leckerli gegeben.
Deine Datei habe heruntergeladen. Ob ich das alles so hinbekomme weiß ich nicht,
weil ich nicht besonders fit im Linux bin, aber probieren kann ich das ja mal - ich kann nur lernen dabei.
Das Ergebnis kommt aber erst später - vermutlich morgen oder Übermorgen.
Der 18 Jahre alte Kater hat ne Maus angeschleppt. Jetzt muß ich erst mal nachsehen, ob die noch rennt ...
--- Update ---
OK ! Maus entsorgt und dem Kater ein Leckerli gegeben.
Deine Datei habe heruntergeladen. Ob ich das alles so hinbekomme weiß ich nicht,
weil ich nicht besonders fit im Linux bin, aber probieren kann ich das ja mal - ich kann nur lernen dabei.
Das Ergebnis kommt aber erst später - vermutlich morgen oder Übermorgen.
Ähnliche Themen
