OrangePi Zero – mehr Benchmarks

[Tam H. (Firma: Tamoggemon Holding k.s.) (tamhanna)]

Nach der Vorstellung des OrangePi Zero ist es nun an der Zeit, einige Messungen zur Hardware nachzulegen. Neben der Ethernetschnittstelle des Zero sehen wir uns hier auch die GPIO-Performance und das Verhalten gegenüber dem Massenspeicher an.

Worum geht es hier.

Wer einen (am Markt frei verfügbaren) und in unbeschränkter Stückzahl verwertbaren Prozessrechner kaufen möchte, ist im Hause Shenzhen Xunlong seit jeher besser bedient: Das Unternehmen ist ideologiefrei und rein kommerziell.

Die physischen Aspekte und die Prozessor-Leistungsfähigkeit des Zero haben wir unter Beitrag "Orange Pi Zero im Blick: Raspberry Pi Zero-Alternative mit freier Verfügbarkeit" vorgestellt - nun ist es an der Zeit, die „kleinste“ und HDMI-lose Vertreterin des Orange Pi-Ökosystems einem anderen Test zu unterziehen.

Ethernet Rules Supreme!

Während der Raspberry Pi Zero 2W - Nomen est Omen - ausschließlich per WLAN kommuniziert, hat der Orange Pi Zero auch eine „klassische“ Ethernet-Schnittstelle. Zur „Vermessung“ bietet sich die Nutzung des Universal-Benchmarks iperf an, den sie im ersten Schritt nach folgendem Schema installieren:

root@orangepizero:~# sudo apt-get install iperf

iperf-Testläufe setzen immer auch eine Gegenstelle voraus. Der Autor nutzt in den folgenden Schritten seine mit Ubuntu 20.04 laufende Workstation, die über einen NetGear ProSafe-Switch Verbindung zum Prozessrechner aufnimmt. Auf der Workstation ergreifen wir unser Terminalfenster, und starten nach folgendem Schema den Server:

tamhan@TAMHAN18:~$ iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size:  128 KByte (default)
------------------------------------------------------------

An dieser Stelle lässt sich die Ethernetschnittstelle vermessen, was zu folgendem Ergebnis führt:

root@orangepizero:~# iperf -c 192.168.1.68
------------------------------------------------------------
Client connecting to 192.168.1.68, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.71 port 48688 connected with 192.168.1.68 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3] 0.0000-10.0005 sec   113 MBytes  94.5 Mbits/sec

Test mit USB-Stick

Als nächsten Test wollen wir uns die Leistungsfähigkeit der auf dem Board fix verlöteten USB-Schnittstelle ansehen. Interessant ist dabei, dass Armbian angeschlossene USB-Speichermedien von Haus aus nicht mountet    -im ersten Schritt müssen wir das Medium deshalb per FDISK lokalisieren:

root@orangepizero:/media# fdisk -l

Lohn der Mühen ist – idealerweise - die in der Abbildung gezeigte Partitionstabelle, die die vom Orange Pi gesichteten Partitionen am USB-Speicher auflistet. Sofern sie in Bezug auf die „Detektierung“ auf Nummer sicher gehen wollen, bietet sich vorher die Nutzung von LSUSB an.

Im nächsten Schritt müssen wir einen Mountpunkt erzeugen und den USB-Stick nach folgendem Schema mounten:

root@orangepizero:/media# mkdir usbstick
root@orangepizero:/media# mount /dev/sda /media/usbstick/
root@orangepizero:/media# cd usbstick/
root@orangepizero:/media/usbstick# ls

Im nächsten Schritt bietet sich auch schon die „Ausführung“ des eigentlichen Benchmarks an, die wir abermals unter Nutzung des aus dem letzten Artikel zum Thema bekannten Sysbench durchführen:

root@orangepizero:/media/usbstick/workspace# sysbench --test=fileio --file-total-size=3G --file-test-mode=rndrw --max-time=300 --max-requests=0 run

Lohn der Mühen ist die Abarbeitung der etwa 300 Sekunden in Anspruch nehmenden Testsuite, die am OrangePi Zero die folgenden Ergebnisse liefert:

File operations:
    reads/s:                      47.14
    writes/s:                     31.42
    fsyncs/s:                     100.86

Throughput:
    read, MiB/s:                  0.74
    written, MiB/s:               0.49

General statistics:
    total time:                          300.4029s

Der Zero 2W ist auch hier etwas schneller:

Zero 2W:

File operations:
    reads/s:                      57.13
    writes/s:                     38.09
    fsyncs/s:                     122.23

Throughput:
    read, MiB/s:                  0.89
    written, MiB/s:               0.60

General statistics:
    total time:                          300.3538s

Angemerkt sei, dass das automatische Mounten von Speichermedien unter ARMbian eine immer interessante Frage ist - unter https://forum.armbian.com/topic/6341-fyi-auto-mount-usb-disk-with-usbmount/ findet sich ein Foren-Thread zur Diskussion. Der einfachste Weg zur Überprüfung der Kollisions-Anfälligkeit besteht darin, zwei SSH-Verbindungen gleichzeitig aufzubauen. iperf lässt sich bei folgendem Aufruf dazu animieren, alle zwei Sekunden Statusinformationen auszugeben:

root@orangepizero:~#  iperf -c 192.168.1.68 -t 30 -i 2
------------------------------------------------------------
Client connecting to 192.168.1.68, TCP port 5001

Der Weg zum „erfolgreichen“ Benchmark ist dann die parallele Ausführung von sysbench und iperf, die zum in der Abbildung gezeigten Ergebnis führt. In Tests des Autors erwies sich der Raspberry Pi Zero W an dieser Stelle übrigens wesentlich anfälliger, er verlor unter iO-Belastung bis zu 30 % der Netzwerk-Bandbreite.

Kleiner IO-Test

Als letzten Versuch wollen wir uns das iO-Kompliment des Raspberry Pi Zero ansehen. Zur Erinnerung: Vergleichsmessungen gegen den Zero 2 finden Sie unter der URL Beitrag "Raspberry Pi Zero 2W im Benchmarktest". Für den eigentlichen Hardwarezugriff steht dabei eine „Forkung“ der WiringPi-Bibliothek zur Verfügung, die Shenzhen Xunlong    auf GitHub pflegt. Unsere erste Amtshandlung ist deshalb – logischerweise - das Herunterladen der fehlenden Dateien:

root@orangepizero:~# git clone https://github.com/orangepi-xunlong/wiringOP.git
Cloning into 'wiringOP'...
remote: Enumerating objects: 607, done.
remote: Counting objects: 100% (136/136), done.
remote: Compressing objects: 100% (31/31), done.
remote: Total 607 (delta 114), reused 113 (delta 105), pack-reused 471
Receiving objects: 100% (607/607), 353.04 KiB | 2.71 MiB/s, done.
Resolving deltas: 100% (394/394), done.

Im nächsten Schritt folgt die übliche, in zwei Schritten durchzuführende Kompilation:

root@orangepizero:~/wiringOP# ./build clean
wiringPi:   [Clean]
. . .

root@orangepizero:~/wiringOP# ./build
wiringPi Build script
=====================

Interessant ist hier, dass ein Aufruf von Make Install nicht notwendig ist. Nach getaner Arbeit können sich stattdessen sofort gpio readall aufrufen, was zum in der Abbildung gezeigten Ergebnis führt:

root@orangepizero:~/wiringOP# gpio readall

Im nächsten Schritt benötigen wir - wie immer - ein Testprogramm, das nach folgendem Schema aufgebaut ist:

#include <wiringPi.h>

int main (void)
{
  wiringPiSetup () ;
  pinMode (14, OUTPUT) ;
  for (;;)
  {
    digitalWrite (14, HIGH) ;
    digitalWrite (14,  LOW) ;
  }
  return 0 ;
}

Beachten Sie, dass die Bibliothek die im „großen Vorbild“ angelegten Namen von Headerdateien und Co eins zu eins übernimmt; die „unterschiedlichen“ Pin-Nummern stammen aus Abbildung drei. Eine gewöhnliche Kompilation nur unter übergeben des Parameters -lwiringPiu scheitert:

root@orangepizero:~# gcc worker.c -lwiringPi
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabihf/10/../../../libwiringPi.so: undefined reference to `crypt'
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabihf/10/../../../libwiringPi.so: undefined reference to `rint'
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabihf/10/../../../libwiringPi.so: undefined reference to `pthread_join'
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabihf/10/../../../libwiringPi.so: undefined reference to `pthread_create'
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabihf/10/../../../libwiringPi.so: undefined reference to `pow'
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabihf/10/../../../libwiringPi.so: undefined reference to `shm_open'
/usr/bin/ld: /

Funktionsfähig ist das Kompilat nur bei folgender Parametrisierung:

root@orangepizero:~# gcc -pthread worker.c -lwiringPi -lcrypt -lm -lrt

Auf einem Modulationsdomänenanalysator (Detailbeschreibung des Meßgeräts unter https://www.youtube.com/watch?v=lBLEfVUVGyU) sehen wir dann das in der Abbildung gezeigte Ergebnis.

(Bildquelle alle: Ing. Tam HANNA / BSc, eigene Kamera)

[Stefan M. (interrupt)]

Danke für den Content,
interessant wäre auch ein tabellarischer Vergleich der 
Benchmark-Ergebnisse zwischen Orange und Rasp

[Jakob L. (jakob)]

So wie ich das sehe messen die USB-Benchmarks mit einem einfachen 
USB-Stick im wesentlichen die Geschwindigkeit des Sticks und nicht die 
Geschwindigkeit des Pis. Gerade bei random access werden billige 
Flash-Speicher (USB-Sticks/SD-Karten) oft extrem langsam, die Werte im 
Benchmark wundern mich da überhaupt nicht. Für einen Aussagekräftigen 
Vergleich zwischen verschiedenen Boards könnte man das Ganze mit einer 
USB-SSD wiederholen, da wird dann wahrscheinlich tatsächlich die 
USB-Schnittstelle bzw. die CPU zum Flaschenhals.