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 https://www.mikrocontroller.net/topic/orange-pi-zero-im-blick-raspberry-pi-zero-alternative-mit-freier- 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:
1root@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:
1tamhan@TAMHAN18:~$ iperf –s
2————————————————————
3Server listening on TCP port 5001
4TCP window size: 128 KByte (default)
5————————————————————
An dieser Stelle lässt sich die Ethernetschnittstelle vermessen, was zu folgendem Ergebnis führt:
1root@orangepizero:~# iperf –c 192.168.1.68
2————————————————————
3Client connecting to 192.168.1.68, TCP port 5001
4TCP window size: 43.8 KByte (default)
5————————————————————
6[ 3] local 192.168.1.71 port 48688 connected with 192.168.1.68 port 5001
7[ ID] Interval Transfer Bandwidth
8[ 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:
1root@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:
1root@orangepizero:/media# mkdir usbstick
2root@orangepizero:/media# mount /dev/sda /media/usbstick/
3root@orangepizero:/media# cd usbstick/
4root@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:
1root@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:
1File operations:
2 reads/s: 47.14
3 writes/s: 31.42
4 fsyncs/s: 100.86
5
6Throughput:
7 read, MiB/s: 0.74
8 written, MiB/s: 0.49
9
10General statistics:
11 total time: 300.4029s
Der Zero 2W ist auch hier etwas schneller:
1Zero 2W:
2
3File operations:
4 reads/s: 57.13
5 writes/s: 38.09
6 fsyncs/s: 122.23
7
8Throughput:
9 read, MiB/s: 0.89
10 written, MiB/s: 0.60
11
12General statistics:
13 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:
1root@orangepizero:~# iperf –c 192.168.1.68 –t 30 –i 2
2————————————————————
3Client 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 https://www.mikrocontroller.net/topic/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:
1root@orangepizero:~# git clone https://github.com/orangepi-xunlong/wiringOP.git
2Cloning into ‚wiringOP‚…
3remote: Enumerating objects: 607, done.
4remote: Counting objects: 100% (136/136), done.
5remote: Compressing objects: 100% (31/31), done.
6remote: Total 607 (delta 114), reused 113 (delta 105), pack–reused 471
7Receiving objects: 100% (607/607), 353.04 KiB | 2.71 MiB/s, done.
8Resolving deltas: 100% (394/394), done.
Im nächsten Schritt folgt die übliche, in zwei Schritten durchzuführende Kompilation:
1root@orangepizero:~/wiringOP# ./build clean
2wiringPi: [Clean]
3. . .
4
5root@orangepizero:~/wiringOP# ./build
6wiringPi Build script
7=====================
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:
1root@orangepizero:~/wiringOP# gpio readall
Im nächsten Schritt benötigen wir – wie immer – ein Testprogramm, das nach folgendem Schema aufgebaut ist:
1#include <wiringPi.h>
2
3int main (void)
4{
5 wiringPiSetup () ;
6 pinMode (14, OUTPUT) ;
7 for (;;)
8 {
9 digitalWrite (14, HIGH) ;
10 digitalWrite (14, LOW) ;
11 }
12 return 0 ;
13}
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:
1root@orangepizero:~# gcc worker.c –lwiringPi
2/usr/bin/ld: /usr/lib/gcc/arm–linux–gnueabihf/10/../../../libwiringPi.so: undefined reference to `crypt‚
3/usr/bin/ld: /usr/lib/gcc/arm–linux–gnueabihf/10/../../../libwiringPi.so: undefined reference to `rint‚
4/usr/bin/ld: /usr/lib/gcc/arm–linux–gnueabihf/10/../../../libwiringPi.so: undefined reference to `pthread_join‚
5/usr/bin/ld: /usr/lib/gcc/arm–linux–gnueabihf/10/../../../libwiringPi.so: undefined reference to `pthread_create‚
6/usr/bin/ld: /usr/lib/gcc/arm–linux–gnueabihf/10/../../../libwiringPi.so: undefined reference to `pow‚
7/usr/bin/ld: /usr/lib/gcc/arm–linux–gnueabihf/10/../../../libwiringPi.so: undefined reference to `shm_open‚
8/usr/bin/ld: /
Funktionsfähig ist das Kompilat nur bei folgender Parametrisierung:
1root@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)
Zuerst erschienen bei Mikrocontroller.net News
Quelle: Read More
