Abbildung 7: Das Kompilieren der FST-Quellen demonstriert den Vorteil eines Rechners mit viel Arbeitsspeicher. Im Gegensatz zum RasPi 3B+ und dem Odroid HC1 schafft es der Rock Pi 4, den Bauvorgang auf alle seine Kerne zu verteilen, und gewinnt so wesentlich Zeit.
Sowohl bei einem RasPi 3B+ (4 Kerne, 1 GByte Speicher) als auch beim Odroid HC1 (8 Kerne, 2 GByte Speicher) lief der Make-Befehl im Test nur durch, wenn maximal 2 Kerne zum Einsatz kamen. Ansonsten schlug irgendwann – unabhängig vom zusätzlichen Swapspace – der sogenannte OOM-Killer des Kernels zu (out of memory).
Die Laufzeit des RasPi betrug 2044 Sekunden, der HC1 halbierte das auf 1024 Sekunden. Beide Rechner arbeiteten dabei auf einer SSD, die beim RasPi 3B+ allerdings USB2 ausbremst. Der Rock Pi 4 kam mit zwei CPUs auf 1000 Sekunden, doch dank des zusätzlichen Speichers lief der Build auch mit sechs CPUs durch. Damit kam der Rock Pi 4 bereits nach 666 Sekunden ins Ziel.
Auch diese Runde geht klar an den Rock Pi 4 und zeigt, dass mehr Kerne wie beim HC1 nicht unbedingt mehr Leistung bedeuten, wenn das Gesamtsystem nicht entsprechend ausgelegt ist. Bei einer weniger speicherintensiven Anwendung mag das Pendel aber wieder zugunsten der acht Kerne des HC1 ausschlagen.
Im Netz
Vom Gigabit-Netzwerkanschluss und schnellem Massenspeicher profitieren vor allem Server-Anwendungen. Als Anwendungsfälle für den Home-Bereich bietet sich eine Kopie eines längeren Films (5,3 GByte) von und zum Server an sowie das Kopieren von Dateien mit Rsync, etwa wenn der Inhalt einer Speicherkarte von einem Fotoausflug auf dem Fileserver landen soll. Daneben stand im Test auch das normale Lesen und Schreiben auf den Server per NFS oder Samba auf dem Programm. Neben dem Rock Pi 4 gingen wieder der RasPi 3B++ sowie der HC1 ins Rennen.
Zuerst ermittelten wir die (wenig aussagekräftige) rohe Netzwerkperformance mit Iperf3 – da gab es keine Überraschungen. Die Werte für den Rock Pi 4 (Server: 745 Mbit/s, Client: 942 Mbit/s) und den HC1 (740 Mbit/s und 925 Mbit/s) fielen beinahe identisch aus. Ähnliches galt für NFS und Samba: Der RasPi blieb bei unter 20 MByte/s, während der HC1 und der Rock Pi 4 fast die volle Bandbreite ausnutzten (zum Server: 80 MByte/s, vom Server 105 MByte/s).
Abbildung 8: Auch in Sachen Netzwerkperformance weiß der Rock Pi die Konkurrenz in Schach zu halten. Hier zeigt sich besonders der Flaschenhals der Raspberry-Modelle.
Beim Kopieren der Dateien mit Scp beziehungsweise Rsync zeigten sich ebenfalls deutliche Unterschiede, da der Rock Pi 4 hier seine höhere Systemleistung ausspielen konnte. Er benötigte zum Kopieren konstant nur etwa zwei Drittel der Zeit, die der HC1 brauchte. Der Durchsatz lag dabei bei sehr guten Werten von 60 bis 80 MByte/s. Der RasPi 3B++ landete weit abgeschlagen auf dem letzten Platz, was angesichts des Systemdesigns nicht überrascht: Hier teilen sich Netzwerk und Massenspeicher den USB-Bus; übersteigt das übertragene Dateivolumen die Größe des Caches, bricht die Datenrate auf 20 MByte/s ein. Selbst bei kleinen Dateien erweist sich ein Durchsatz von maximal 40 MByte/s als absolute Grenze.
Stromverbrauch
Angesichts der leistungsstarken Komponenten verwundert es nicht, dass der Rock Pi 4 ein deutlich höher spezifiziertes Netzteil benötigt als ein RasPi. Schon die beiden USB-3.0-Ports dürfen zusammen laut Spezifikation 9 Watt ziehen. Wichtiger als die Leistungsaufnahme unter Last ist allerdings oft der Strombedarf im Leerlauf, denn typischerweise langweilen sich SBCs im Alltagsbetrieb. Unter Armbian im Server-Modus – ohne Tastatur, Maus und Bildschirm – gibt sich der Rock Pi 4 mit einer Leistungsaufnahme von 3 Watt genauso genügsam wie der RasPi 3B+.
Aber selbst unter Last zeigt sich der Rock Pi 4 von seiner sparsamen Seite. Beim Test der FST-Kompilation mit per USB 3.0 angeschlossener SSD blieb die Leistungsaufnahme meist bei rund 9 Watt. Vereinzelt traten Spitzen von maximal 11 Watt auf – trotz sechs unter Volllast laufender Kerne und ständiger Zugriffe auf die SSD. Für dieses Szenario würde also auch ein “normales” Netzteil ausreichen.
Unfreiwilligerweise haben wir diesen Fall getestet: Bei einer Neuinstallation, gefolgt von einem System-Upgrade, steckten wir das Netzkabel aus Versehen in ein normales 5V/2,5A-Netzteil, das sich auch für den Raspberry Pi eignet. Die Leistung dieses Netzteils erwies sich dabei als völlig ausreichend – allerdings wurde der Rock Pi 4 hier ohne stromhungrige USB-Festplatten und ohne Bildschirm betrieben.
Besser als der RasPi macht es der Rock Pi 4 nach dem Herunterfahren. Während das Original es nicht schafft, alle Komponenten abzuschalten, und weiterhin Strom verbraucht (teilweise mehr als im Idle-Betrieb), reduziert der Herausforderer seinen Bedarf auf fast null. Ein recht obskures Verhalten legte dabei allerdings das Original-Armbian an den Tag: Die grüne Status-LED bleibt eine Weile an; nach einiger Zeit stieg die Leistungsaufnahme schrittweise auf 30 Watt an, um dann zusammen mit dem Erlöschen der LED auf null zu fallen. Das Radxa-Armbian zeigt dieses Verhalten nicht. Hier lag der Stromverbrauch direkt nach dem Shutdown unterhalb der Messschwelle, die grüne LED blieb allerdings konstant an.
Der Rock Pi 4 verfügt auch über eine Echtzeituhr (RTC), die er in den PMIC integriert. Rein theoretisch sollte damit der Rock Pi 4 zeitgesteuert aufwachen können, auf dem Testsystem ließ sich diese Funktion allerdings noch nicht verwenden.
Fazit
Radxas Flaggschiff bietet alles, was Anwender am RasPi schmerzlich vermissen: stabile Stromversorgung, schnelleres LAN, schnellerer Massenspeicher, Hardware-Unterstützung von HECV/H.265, eine RTC, einen ADC-Eingang auf der GPIO-Leiste. Das Board löst also sofort den Haben-will-Reflex aus, und die Erwartungshaltung wird in der Praxis auch bestätigt.
Der Rock Pi 4 ließe sich also zu Recht als Next-Generation-Pi ansehen, Jammern über den Rock Pi 4 klappt nur auf hohem Niveau. Als größte Fehlentscheidung des Herstellers erscheint die Wahl des Formfaktors des RasPi. Wegen des notwendigen Kühlers passt der Rock Pi 4 sowieso in kein RasPi-Gehäuse, und auch die GPIO-Leiste ist nicht voll kompatibel – warum also nicht ein besseres Format wählen, bei dem die Kabel nicht in mehreren Richtungen abstehen? Auch das Problem mit dem unzugänglichen eMMC-Speicher hätte ein anderes Board-Format beseitigt.
