Menü

Hardware oDroid Software

oDroid XU4: Tweaks unter Ubuntu 18.04 und Kernel 4.14

oDroid XU4 Tweaks

Wie viele andere auch, bin ich daran interessiert aus meinem oDroid XU4 das Maximum herauszuholen. So habe ich über die Zeit für meinen oDroid XU4 Tweaks entdeckt, die manchmal mehr und manchmal weniger gebracht haben. In diesem Beitrag möchte ich eine kleine Übersicht dazu bieten. Sollte ich in Zukunft auf weitere Verbesserungen stoßen, werde ich diese in diesem Beitrag editieren. Wenn ihr noch Vorschläge habt, könnt ihr diese natürlich gerne in den Kommentaren kundtun, sodass ich sie anschließend mit aufnehmen kann. Ich habe alle Tweaks unter Ubuntu 18.04 und dem aktuellen oDroid Linux-Kernel 4.14 für diesen Beitrag getestet und die meisten davon auch dauerhaft aktiv.

Vorab möchte ich darauf hinweisen, dass jegliche Anpassungen oder Veränderungen selbstverständlich auf eigene Gefahr hin durchgeführt werden. Ich kann für nichts eine Haftung übernehmen. Sämtliche Änderungen können die Stabilität oder Garantie des Systems gefährden!

Inhaltsverzeichnis

  1. Overclocking
    1. CPU Overclocking und Benchmarks
    2. RAM Overclocking und Benchmarks
  2. IO Geschwindigkeit erhöhen
    1. USB3.0 Ports und Ethernet Port den BIG.cores zuweisen
    2. UASP für USB 3.0 Festplatten nutzen
  3. Stromverbrauch reduzieren
    1. CPU Kerne deaktivieren
    2. GPU heruntertakten

Overclocking

CPU Overclocking und Benchmarks

HardKernel rät dringends davon ab an den bestehenden Gigahertz-Werten etwas zu verändern. Es kann zu Stabilitäts- und Hitze-Problemen kommen. Um gegen letzteres vorzugehen, kann ich euch meinen Beitrag zum Lüfter Wechsel des oDroid XU4 empfehlen. Gemeint ist nämlich Thermal Throttling – also das heruntertakten der CPU, um einen Hitzeschaden zu vermeiden. Stabilitätsproblemen setzt man sich leider zwangsweise aus, bis man ein perfekt funktionierendes Setup zusammengestellt hat. Dies ist einer der erfolgversprechendsten oDroid XU4 Tweaks von allen!

Standardmäßig werden die vier little.cores (das sind die sparsamen ARM-Kerne des Prozessors) und die vier BIG.cores (ratet mal :)) mit einem Maximaltakt von 1,5 GHz und 2,0 GHz betrieben. Ich werde euch folgend erklären, wie man den Kernel anpasst und kompiliert, um schlussendlich 1,6 GHz und 2,1 GHz als Maximaltakt nutzen zu können. Damit konnte ich innerhalb meiner Testphase (1 Woche) keinerlei Probleme oder Abstürze feststellen und würde es als stabil beschreiben. Darüber hinaus bin ich nicht gegangen.

Zur Verdeutlichung des Leistungszuwachses habe ich mal einen kleinen Benchmark mit sysbench durchgeführt. Hier sind zu aller erst die Ergebnisse (gering ist besser):

Kern-TypBenchmark Ergebnis ohne OverclockBenchmark Ergebnis mit OverclockUnterschied
little.cores35,644 Sekunden33,408 Sekunden-6,27%
BIG.cores21,695 Sekunden20,624 Sekunden-4,94%
Alle13,583 Sekunden12,994 Sekunden-4,34%

Wie man sieht, kann man bereits mit einer Anpassung von 0,1 GHz ordentlich Mehrleistung herausholen. Insbesondere den litte.cores mit dem geringeren Basistakt von 1,5 GHz stehen die extra 100 MHz sichtlich gut. Die Terminal-Kommandos für die Benchmarks sehen so aus:

Shell
1
2
3
taskset -c 0,1,2,3 sysbench --test=cpu --num-threads=4 run # little.cores
taskset -c 4,5,6,7 sysbench --test=cpu --num-threads=4 run # BIG.cores
sysbench --test=cpu --num-threads=8 run # alle Kerne

Alle Commands wurden dreimal ausgeführt und von den Ergebnissen wurde der Durchschnitt genommen. Als CPU Governor wurde selbstverständlich Performance gesetzt. Nun aber genug zum Benchmark! Wie kann man die CPU übertakten? Dank ridge’s Beobachtungen im Code des Kernels, hat er eine kleine Anleitung geschrieben. Aus der Anleitung habe ich für euch eine Copy-Pasta gemacht; einfach als root einloggen und das folgende Skript in eurer Terminal kopieren. Die Kompilierung kann bis zu 30 Minuten dauern – holt euch also in der Zwischenzeit ruhig einen Kaffee und checkt eure Mails.

Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
# Letzte Aktualisierung: 27. Juli 2019
 
# Git Repo klonen
cd /tmp
git clone --depth 1 https://github.com/hardkernel/linux -b odroidxu4-4.14.y
cd linux
 
# die neuen Taktraten einfügen
sed -i 's/<1500000000>/<1600000000>/g' arch/arm/boot/dts/exynos5422-cpus.dtsi
sed -i 's/<2000000000>/<2100000000>/g' arch/arm/boot/dts/exynos5422-cpus.dtsi
 
sed -i '/&cluster_a15_opp_table {/a \
        opp-2100000000 { \
                opp-hz = /bits/ 64 <2100000000>; \
                opp-microvolt = <1312500>; \
                clock-latency-ns = <140000>; \
        };' arch/arm/boot/dts/exynos5800.dtsi
 
sed -i '/&cluster_a7_opp_table {/a \
        opp-1600000000 { \
                opp-hz = /bits/ 64 <1600000000>; \
                opp-microvolt = <1250000>; \
                clock-latency-ns = <140000>; \
        };' arch/arm/boot/dts/exynos5800.dtsi
 
sed -i '/PLL_35XX_RATE(2000000000, 250, 3, 0),/i \
        PLL_35XX_RATE(2100000000, 175, 2, 0),' drivers/clk/samsung/clk-exynos5420.c
 
sed -i '/{ 2000000, E5420_EGL_DIV0(3, 7, 7, 4), },/i \
        { 2100000, E5420_EGL_DIV0(3, 7, 7, 4), },' drivers/clk/samsung/clk-exynos5420.c
 
sed -i '/{ 1500000, E5420_KFC_DIV(3, 5, 3), },/i \
        { 1550000, E5420_KFC_DIV(3, 5, 3), },' drivers/clk/samsung/clk-exynos5420.c
 
# Kernel kompilieren, siehe: https://wiki.odroid.com/odroid-xu4/software/building_kernel#y
apt update && apt install -y git gcc g++ build-essential libssl-dev bc
make odroidxu4_defconfig
make -j8
make modules_install
cp -f arch/arm/boot/zImage /media/boot
cp -f arch/arm/boot/dts/exynos5422-odroidxu3.dtb /media/boot
cp -f arch/arm/boot/dts/exynos5422-odroidxu4.dtb /media/boot
cp -f arch/arm/boot/dts/exynos5422-odroidxu3-lite.dtb /media/boot
sync

Geschafft? Keine Fehlermeldung? Dann könnt ihr den oDroid XU4 jetzt mit reboot  neustarten. Beim Starten wird der neu kompilierte Kernel geladen und ab sofort stehen euch Maximaltaktraten von 2,1 und 1,6 GHz anstelle von 2,0 und 1,5 GHz zur Verfügung!

RAM Overclocking und Benchmarks

Die Taktrate von RAM gibt vor wie hoch die Datenrate ist. Ganz simpel ausgedrückt: je mehr, desto schneller. Hardkernel hat es äußerst einfach gemacht den oDroid XU4 RAM zu übertakten. Standardmäßig läuft dieser mit 825 MHz und es ist extrem simpel diesen auf 933 MHz zu übertakten. Dazu müsst ihr nur in der /media/boot/boot.ini  die Zeile setenv ddr_freq 825  suchen und die 825 mit 933 austauschen. Ansonsten habe ich auch hier wieder eine Copy-Paste für euch bereit:

Shell
1
sed -i 's/setenv ddr_freq 825/setenv ddr_feq 933/' /media/boot/boot.ini

Und welche Leistungsverbesserungen kann man dabei erwarten? Ich habe dazu wieder mit sysbench einen kleinen Benchmark durchgeführt. Als Befehl diente sysbench --test=memory --memory-block-size=1K --memory-total-size=10G --num-threads=1 run  dazu. Die Total Execution Time verbesserte sich dabei von 10,733 Sekunden auf 10,592 Sekunden – eine Veränderung von -1,31%. In diesem Falle sollte also jeder selbst entscheiden, ob er einen erhöhten Stromverbrauch für diese „Leistungsverbesserung“ hin nimmt. Ich, für meinen Teil, habe 933 MHz aktiviert. Die kleinen oDroid XU4 Tweaks sorgen eben für das gute Gesamtpaket 🙂

IO Geschwindigkeit erhöhen

USB3.0 Ports und Ethernet Port den BIG.cores zuweisen

Als Quelle für den folgenden Beitrag ein Dank an Obihoernchen! Das folgende stammt aus seinem Blogbeitrag und wurde von mir zu diesem Beitrags für oDroid XU4 Tweaks übernommen. Ihr solltet unbedingt mal auf seinem Blog vorbeischauen!

Standardmäßig werden Aufgaben/Events, die durch den Ethernet- oder die USB-Ports entstehen (Interrupts), auf alle Kerne verteilt. So kann es passieren, dass ein little.core die Aufgabe zugeteilt bekommt 10 GB aus dem Internet herunterzuladen, wo es ein BIG.core doch in wesentlich kürzerer Zeit absolvieren könnte. Um sicherzustellen, dass dies in Zukunft von den BIG.cores gemacht wird, solltet ihr zu Beginn sicherstellen, dass der Service irqbalance deaktiviert ist:

Shell
1
systemctl disable irqbalance

Anschließend öffnen wir die Datei /etc/rc.local  und fügen folgendes vor dem exit 0  ein:

Shell
1
2
3
4
5
6
# usb2
echo 6 > /proc/irq/103/smp_affinity_list
# usb3
echo 5 > /proc/irq/104/smp_affinity_list
# network (usb3)
echo 4 > /proc/irq/105/smp_affinity_list

Laut den Benchmarks von Obihoernchen wurden damit um bis zu 100 Mbit (12,5 MB/s) schnellere Transfers erreicht. Bei mir ist dies mittlerweile eine Standard-Einstellung und ich kenne es gar nicht mehr ohne.

UASP für USB 3.0 Festplatten nutzen

Dies ist ein allgemeiner Tipp und hat kein Code-Beispiel oÄ. parat, ist aber einer meiner liebsten oDroid XU4 Tweaks. Wie in meinem Beitrag oDroid XU4: SSD vs. eMMC Vergleich (Boost!) damals ausführlich beschrieben und getestet, kann ich nur wärmstens empfehlen eine SSD mit einem SATA-to-USB Adapter zu verwenden, der UASP unterstützt. Dazu hier noch einmal die Tabelle aus dem Beitrag:

TypLese-Zeiten (Cache)Lese-Zeiten (Direct)Schreib-Zeiten
eMMC804,54 MB/s155,44 MB/s45,50 MB/s
SSD (ohne UASP)890,57 MB/s106,09 MB/s125,00 MB/s
SSD (mit UASP)888,20 MB/s343,56 MB/s205,00 MB/s

Die UASP Adapter kosten kaum weniger und bieten ungeheuerliche Mehrleistung.

Stromverbrauch reduzieren

Viele benutzen den oDroid XU4 sicherlich als kleinen stromsparenden Home-Server – genau wie ich. Um den Stromverbrauch im 24/7 Betrieb ein wenig zu reduzieren, kommen folgend noch ein paar Tipps.

CPU Kerne deaktivieren

Um einzelne Kerne zu deaktivieren bedarf es kaum eines Aufwandes. Vorerst müsst ihr aber wissen das CPU0-CPU3 eure little.cores und CPU4-7 eure BIG.cores sind. Je nachdem, welche Anforderungen ihr an euren oDroid XU4 habt, solltet ihr abwägen welche Kerne ihr genau deaktiviert.

Shell
1
2
# die 0 bei 'cpu0' im folgenden Befehl dabei mit dem gewünschten Kern austauschen
echo 0 > /sys/devices/system/cpu/cpu0/online

GPU heruntertakten

Wiedermal stammt folgender Tipp von Obihoernchens Blog. Dieses mal geht es darum die GPU, den Grafikprozessor vom oDroid XU4, herunterzutakten. Im reinen Server-Betrieb läuft diese nämlich immer auf maximal Taktrate von 600 MHz, ohne dass man diese im Regelfall wirklich beansprucht. Das Obihoernchen hat auch wieder Messungen durchgeführt und konnte wohl eine Strom-Einsparung von etwa 20% erzielen!

Um das zu erreichen, müssen wir zuallererst das Paket sysfsutils mittels APT installieren: apt update && apt install sysfsutils

Anschließend müssen wir in der /etc/sysfs.conf  abhängig von eurem Kernel (mit uname -a  könnt ihr herausfinden, welchen ihr gestartet habt) folgendes einfügen:

Shell
1
2
3
4
5
6
7
8
# wenn Kernel 3.10 dann folgendes einfügen:
devices/11800000.mali/dvfs_max_lock = 177
# wenn Kernel 4.9 dann folgendes einfügen:
devices/platform/11800000.mali\:/devfreq/11800000.mali\:/governor = powersave
# wenn Kernel 4.14 dann folgendes einfügen:
devices/platform/11800000.mali/devfreq/devfreq0/governor = powersave

Mit einem abschließenden systemctl restart sysfsutils  ist die niedrigere Taktung aktiv.

oDroid XU4 Tweaks & Tuning

Schlussendlich steckt im oDroid XU4 viel Potenzial, welches ausgeschöpft werden kann. Ich denke ich habe mit diesem Artikel einige Tricks offenbart, die womöglich noch nicht jedem bekannt gewesen sind. Solltet ihr ein weiteres Optimierungspotential sehen, könnt ihr dies gerne in den Kommentaren mit uns teilen.

Mit diesem Artikel endet dann auch meine Artikelserie zum oDroid XU4. Ich hab den oDroid N2 bereits seit mehreren Wochen neben mir und freue mich auf neue spannende Artikel mit dem kleinen Racker!

Ähnliche Beiträge:

Kommentare (3)

  2. Die Anleitung zum Heruntertakten der GPU des Odroid XU4 funktioniert leider nur unter Debian und dessen Derivaten da die ’sysfsutils‘ in der Form z.B. unter ArchLinuxArm (alarm) nicht zur Verfügung stehen.

    Eine ’sysfs.conf‘ oder eine ’sysutilsfs.service‘ unit existieren dort nicht, die default Einstellung des governors ist ’simple-ondemand‘ und macht genau: gar nichts!

    Wenn man Glück hat läuft die Mali-GPU nach boot/reboot mit „177000000“, oft aber mit „420000000“ und der Wert bleibt lastunabhängig immer gleich.

    Dennoch lässt sich auch unter ALARM der governor der GPU auf powersave und somit konstant und zuverlässig auf „177000000“ drosseln:

    # /etc/udev/rules.d/50-scaling-governor.rules
    SUBSYSTEM==“devfreq“, ACTION==“add“, KERNEL==“11800000.gpu“, RUN+=“/bin/sh -c ‚echo powersave > /sys/devices/platform/soc/11800000.gpu/devfreq/11800000.gpu/governor'“

    An die Werte für SUBSYSTEM und KERNEL kommt man mit udevadm:

    # udevadm info –attribute-walk –path=/devices/platform/soc/11800000.gpu/devfreq/11800000.gpu
    …
    looking at device ‚/devices/platform/soc/11800000.gpu/devfreq/11800000.gpu‘:
    KERNEL==“11800000.gpu“
    SUBSYSTEM==“devfreq“
    DRIVER==““
    ATTR{available_frequencies}==“177000000 266000000 350000000 420000000 480000000 543000000 600000000″
    ATTR{available_governors}==“userspace powersave performance simple_ondemand“
    ATTR{cur_freq}==“177000000″
    ATTR{governor}==“powersave“
    ATTR{max_freq}==“600000000″
    ATTR{min_freq}==“177000000″
    ATTR{name}==“11800000.gpu“
    ATTR{power/control}==“auto“
    ATTR{power/runtime_active_time}==“0″
    ATTR{power/runtime_status}==“unsupported“
    ATTR{power/runtime_suspended_time}==“0″
    ATTR{target_freq}==“177000000″
    …

Schreibe einen Kommentar