Forum: PC Hard- und Software OrangePi Zero – mehr Benchmarks


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Tam H. (Firma: Tamoggemon Holding k.s.) (tamhanna)


Angehängte Dateien:

Lesenswert?

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:

1
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:

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

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

1
root@orangepizero:~# iperf -c 192.168.1.68
2
------------------------------------------------------------
3
Client connecting to 192.168.1.68, TCP port 5001
4
TCP 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:

1
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:

1
root@orangepizero:/media# mkdir usbstick
2
root@orangepizero:/media# mount /dev/sda /media/usbstick/
3
root@orangepizero:/media# cd usbstick/
4
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:

1
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:

1
File operations:
2
    reads/s:                      47.14
3
    writes/s:                     31.42
4
    fsyncs/s:                     100.86
5
6
Throughput:
7
    read, MiB/s:                  0.74
8
    written, MiB/s:               0.49
9
10
General statistics:
11
    total time:                          300.4029s

Der Zero 2W ist auch hier etwas schneller:

1
Zero 2W:
2
3
File operations:
4
    reads/s:                      57.13
5
    writes/s:                     38.09
6
    fsyncs/s:                     122.23
7
8
Throughput:
9
    read, MiB/s:                  0.89
10
    written, MiB/s:               0.60
11
12
General 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:

1
root@orangepizero:~#  iperf -c 192.168.1.68 -t 30 -i 2
2
------------------------------------------------------------
3
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 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:

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

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

1
root@orangepizero:~/wiringOP# ./build clean
2
wiringPi:   [Clean]
3
. . .
4
5
root@orangepizero:~/wiringOP# ./build
6
wiringPi 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:

1
root@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
3
int 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:

1
root@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:

1
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)


: Bearbeitet durch NewsPoster
von Stefan M. (interrupt)


Lesenswert?

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

: Bearbeitet durch User
von Jakob L. (jakob)


Lesenswert?

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.

Dieser Beitrag kann nur von angemeldeten Benutzern beantwortet werden. Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail, Yahoo oder Facebook? Keine Anmeldung erforderlich!
Mit Google-Account einloggen | Mit Facebook-Account einloggen
Noch kein Account? Hier anmelden.