Die Prozessrechner werden dabei – Abbildung 1 zeigt ein Beispiel aus dem Unternehmen des Autors – meist als „Compute Core“ huckepack auf eine Platine gepackt, die in vielen Fällen noch einen zusätzlichen Zweit-Prozessor für Energieverwaltung und Co. mitbringt (siehe Kasten).
Aus der Konstanz derartiger Platinen ergibt sich, dass die Formfaktoren eines Prozessrechners, zumindest nach dessen Etablierung im Markt, nur noch sehr schwer geändert werden können. Die Raspberry Pi Foundation hat den Zero 2W vor einiger Zeit aktualisiert. Nun ist es an der Zeit, einen Blick auf dieses (auch zur Ausführung von Java-Payloads exzellent geeignete) System zu werfen.
Abb. 1: Der Orange Pi kümmert sich um die Verarbeitung der von der hauseigenen Hardware generierten Informationen
Kombinatorisch intelligent!
Der Autor hat vor einiger Zeit in Zusammenarbeit mit Mikrochip eine Application Note verfasst, die die Nutzung eines Zweit-Prozessors zur Umgehung diverser Probleme von Prozessrechnern illustriert. Unter der URL https://www.microchip.com/DS00004121 findet sich das Dokument.
Blick von oben
Im Bereich der Raspberry Pi‘schen Prozessrechner gibt es seit einiger Zeit eine Dichotomie. Abbildung 2 zeigt ein „Familienfoto“, das alle im Hause Ebenezer Upton angebotenen Formfaktoren vergleicht.
Ganz rechts in der Abbildung findet sich dabei der Raspberry Pi Pico. Es ist eine „Sondervariante“ des Raspberry Pi, die auf dem als RP2040 bezeichneten Chip basiert – dies ist ein hauseigener Mikrocontroller der Raspberry Pi Foundation. Für Java-Programmierer ist dieser Chip schon aus dem Grund nicht wirklich brauchbar, weil er – logischerweise – nur Echtzeitbetriebssysteme, aber kein Linux (oder gar Windows) ausführen kann.
Abb. 2: Im Raspberry Pi-Land, da wimmelt es
Als Nächstes sehen wir die Raspberry Pi W-Familie: Sie haben schon einen vollwertigen Linux-Prozessrechner und ein Funkmodul sowie einen HDMI-Ausgang, sind im Bereich des Arbeitsspeichers aber immer auf 512 Megabyte beschränkt. Ganz links finden sich dann die „vollwertigen“ Varianten Model A und Model B, die der Autor an dieser Stelle als bekannt voraussetzen möchte.
Ob des vergleichsweise geringen Arbeitsspeicher-Ausbaus, aber auch des sehr geringen Gewichts und der kleinen physikalischen Abmessungen ist die Zero W-Familie seit jeher als Compute Core für grafiklose Aufgaben vorgesehen. Bei einem Listenpreis von 15 USD kann es sogar vernünftiger sein, eine Lösung mit Java-IP um einen Zero W herum aufzubauen. MicroEJ mag zwar die Nutzung eines (preiswerteren) ESP 32- oder STM32-Chips erlauben, kostet aber nicht unerhebliche Lizenzgebühren und setzt zudem Änderungen an der Java-Applikation voraus.
Ob der direkten Abstammung von Debian lässt sich Java-Code indes – normalerweise – am Zero W ohne große Modifikationen ausführen; das gilt insbesondere dann, wenn der Code bereits auf einer unixoide Plattform verwendet wird.
Legen wir die beiden Systeme gegenüber, so präsentiert sich der Neuling wie in Abbildung 3 gezeigt. Der wichtigste Unterschied zum Vorgänger ist, dass die Raspberry Pi Foundation – wohl zum Einsparen der Kosten – die Aufgabe des Anlötens des 40 Pin-Headers fortan an den Endkunden überträgt: Derartige Header sind nicht besonders teuer, ob des hohen Pin-Abstands gelingt das Löten auch zittrigen Personen. Sonst sind die beiden Systeme identisch – der Neuling wiegt gute 2 Gramm mehr.
Aus „physikalischer Sicht“ bleibt sonst alles beim Alten: Wer also schon eine auf dem Zero W basierende Lösung hat, kann auf diese Art und Weise „aktualisieren“.
Abb. 3: Aus Sicht des Formfaktors gibt es keinen Unterschied zwischen den Zeros
Umbruch im Hintergrund
Im Laufe der letzten Monate gab es im Raspberry Pi-Ökosystem eine durchaus wichtige Umstellung – das bisher als Raspbian bezeichnete Betriebssystem hört fortan auf den Namen Raspberry Pi OS. Es basiert zwar nach wie vor auf Debian – die Umbenennung erfolgte im Rahmen von Anpassungen an den 64 Bit-Prozessor, der einst mit dem Raspberry Pi 3 in die Welt des Raspberry Pi-Bastlers kam.
Die nach Ansicht des Autors „wichtigste“ Änderung ist, dass auf der unter https://www.raspberrypi.com/software/operating-systems/ bereitstehenden Webseite nun mehrere Varianten zur Verfügung stehen – neben einer in den folgenden Artikelschritten im Allgemeinen verwendeten „universellen“ Version von Raspberry Pi OS gibt es auch eine Variante, die nur für Prozessrechner mit 64 Bit-Prozessor geeignet ist.
Außerdem gibt es nun zwei Varianten – neben der auf Debian 11, auch als Bullseye bezeichneten Version pflegt die Raspberry Pi Foundation derzeit auch eine ältere Variante auf Basis zehn (Buster).
Sei dem, wie es sei, werden wir in den folgenden Schritten zwei Varianten verwenden – die Benchmarks erfolgen unter Nutzung der Version 2022-04-04-raspios-bullseye.img.xz, während die 64 Bit-spezifischen Versuche mit der Image-Datei 2022-04-04-raspios-bullseye-arm64.img.xz erfolgen.
Diese auf den ersten Blick redundante Vorgehensweise ist schon deshalb interessant, weil Oracle beziehungsweise Sun im Rahmen des erstmaligen Aufkommens von 64 Bit-Prozessoren für Desktops feststellten, dass sich die höhere Wortbreite nicht unbedingt positiv auf die Performance auswirkt. Das lag nach Analyse daran, dass 64 Bit-Adresszeiger nun mal „länger“ sind, was manche Operationen wohl aufgrund des Speicher-Engpasses unterm Strich verlangsamt. Sei dem, wie es sei, werden die Images im nächsten Schritt auf Speicherkarten kopiert. Im Interesse maximaler Konstante wird der Autor ein und dieselbe SD-Karte verwenden und diese mehrmals mittels Cardreader beschreiben. Dies ist erforderlich, weil selbst dieselbe Charge in vielen Fällen unterschiedlich schnell und unterschiedlich langsam arbeitende Exemplare aufweist.
Wer als Hostsystem – wie der Autor – Ubuntu einsetzt, muss an dieser Stelle übrigens umdenken. Die Archivdateien müssen vor der Auslieferung auf die SD-Karte nicht erst entpackt werden – der ImageWriter ist in der Lage, den Extraktionsprozess während der Auslieferung der Informationen durchzuführen.
Die eigentliche Inbetriebnahme zeigt dann, dass der Zero 2 W – wie auch sein Vorgänger – „zwischen“ den Zeilen steht. Die Energieversorgung erfolgt wie bei den ganz alten Raspberry Pi durch einen MicroUSB-Port. Achten Sie darauf, den mit Pwr In beschrifteten zu erwischen. Der mit USB beschriftete Port ist stattdessen zum Anschließen von Tastatur und Maus vorgesehen – ein Hub ist (logischerweise) erforderlich, weil nur ein einziger Port zur Verfügung steht. Im Bereich der Bildverarbeitung zeigte man sich dann konservativ: Der HDMI-Port ist vom Typ MiniHDMI; modernere Raspberry Pis nutzen die kleinere, aber minimal höhere Variante MicroHDMI. Daraus folgt, dass die Nutzung eines dedizierten Adapters erforderlich ist.
Diese im Laborbetrieb ärgerliche Einschränkung ist in der Praxis allerdings nicht so schlimm: Im Bereich des Videokabels setzen Sie sehr wahrscheinlich sowieso auf eine Spezialanfertigung; der Austausch des normalerweise verwendeten Connectors gegen einen anderen dürfte ab Stückzahlen von einigen Dutzend keine Probleme verursachen.
Die Verwendung des MicroUSB-Ports zur Stromversorgung ist derweil sowieso eine sehr dämliche Idee – das in Abbildung 4 gezeigte Pinout des Zero 2W, das übrigens mit allen anderen Raspberry Pis geteilt ist, zeigt, dass die Stromversorgung auch „direkt“ über den 40 Pin Header erfolgen kann, was für die Robustheit der Gesamt-Lösung vorteilhaft ist.
Abb. 4: Das GPIO-Pinout ist bei fast allen Raspberry Pis kommunal, https://www.raspberrypi.com/documentation/computers/images/GPIO-Pinout-Diagram-2.png
Bullseye ist "unruhiger"
Wer den Raspberry Pi für eine „Performance-empfindliche“ MSR-Anwendung einsetzt, ist gut beraten, die vom Autor unter https://www.mikrocontroller.net/topic/raspberry-pi-zero-2w-im-benchmarktest zur Verfügung gestellten Modulationsdomänenanalyse-Diagramme anzusehen. Der Nachfolger erweist sich im Vergleich wesentlich „Wellenform-instabiler“.
Allgemein ist auffällig, dass sich neue Betriebssystem-Images vergleichsweise viel Zeit lassen, bis nach dem Anstecken der Stromversorgung Informationen am Bildschirm erscheinen. Im Rahmen des ersten Starts warf der Zero 2W des Autors die übliche Meldung über die Umkonfiguration der SD-Karte, was etwas Zeit in Anspruch nimmt. „Lustig“ ist außerdem, dass das Image während dem Start manchmal Fehlermeldungen auswirft, die auf die Nicht-Konfigurierbarkeit eines per UART ansprechbaren Bluetooth-Modems hinweisen.
Nach dem erfolgreichen Start des Prozessrechners sehen wir eine neue Installations-Oberfläche, die stilistisch verschiedene Prozessrechner und die dazugehörigen Komponenten auflistet.
An dieser Stelle gibt es allerdings eine kleine Neuigkeit – der in Abbildung 5 gezeigte Installations-Schritt fordert den Benutzer dazu auf, sowohl einen Benutzernamen als auch ein Passwort einzugeben. Bisher ließ sich die OOBE-Installation nur durch Eingabe eines Passworts abschließen, was zum Default-Benutzernamen Pi führte. Aufgrund neuartiger Regulationen in einigen Ländern hat die Raspberry Pi Foundation an dieser Stelle nun allerdings die Daumenschrauben enger angezogen.
Abb. 5: Die Vergabe des Benutzernamens muss nun explizit erfolgen
Interessant ist in diesem Zusammenhang, dass die Raspberry Pi Foundation in Bezug auf die Sicherheit enge Richtlinien anliegt. Wer überhaupt kein Passwort vergibt, oder die bekannte Variante Pi/Raspberry auswählt, wird mit den in den Abbildungen 6 und 7 gezeigten Fehlermeldungen „gemaßregelt“.
Immerhin lässt sich die in Abbildung 7 gezeigte Fehlermeldung ignorieren, was insbesondere zum „Weiterverwenden“ alter Programme, die von Pi als Benutzername ausgehen, hilfreich ist. Sonst verhält sich die Installation allerdings so, wie sie es erwarten würden. „Wichtig“ ist in diesem Zusammenhang nur, dass der Raspberry Pi Zero 2 W ob seines Speicherausbaus von nur 512 MB einen „Gutteil“ der in Debian Bullseye eingeführten neuen Features nicht nutzen kann. Das gilt insbesondere für die Desktop-Oberfläche, die nach wie vor eine Spezialvariante des früher verwendeten Window-Managers nutzt.
Abb. 6: Benutzerkonten ohne Passwort sind unzulässig …
Abb. 7: Während die Verwendung „häufiger“ Kombinationen noch zu einer mauligen Meldung führt
Durchführung von Benchmarks
Das „größte“ Problem des Zero ist sein geradezu antiker Prozessor. Der Einkern-Chip bietet nur lachhaft geringe Rechenleistung und ist außerdem nicht zur Abarbeitung von Java 11-VMs befähigt. Der Zero 2W wird mit einem Chip vom BCM2710A1 an den Endkunden gebracht. Es ist ein vier Kerner, der individuell eine Taktrate von bis zu 1 GHz erreicht.
Im Interesse der Lustigkeit wollen wir an dieser Stelle auf die üblichen, mit sysBench durchgeführten Ergebnisse verzichten und stattdessen auf einen Java-spezifischen Benchmark setzen.
Die unter https://renaissance.dev/ bereitstehende Renaissance-Suite hat sich in der Welt von Java mittlerweile als Quasi-Standard etabliert. Der erste Schritt ist das Überprüfen der von Haus aus in Raspberry Pi OS installierten Java-Version. Es schlägt nach folgendem Schema fehl:
pi@raspberrypi:~ $ java -version -bash: java: command not found
Zur Lösung des Problems reicht es aus, nach folgendem Schema das default-jdk-Paket nachzuinstallieren:
pi@raspberrypi:~ $ sudo apt install default-jdkReading package lists... Done...
Lohn der Mühen ist das Verfügbarwerden eines JDK, das den folgenden Versionsstand exponiert:
pi@raspberrypi:~ $ java -versionopenjdk version "11.0.14" 2022-01-18OpenJDK Runtime Environment (build 11.0.14+9-post-Raspbian-1deb11u1)OpenJDK Server VM (build 11.0.14+9-post-Raspbian-1deb11u1, mixed mode)
Beachten Sie, dieses Kommando nur auf einem Zero 2W auszuführen. Auf älteren Maschinen scheitert es mit einer nach folgendem Schema aufgebauten Fehlermeldung – sie weist auf das Nicht-Vorhandensein von notwendigen CPU-Instruktionen hin:
pi@raspberrypi:~ $ java --versionError occurred during initialization of VMServer VM is only supported on ARMv7+ VFP
Ein Blick auf die unter der Webseite von Renaissance genannten Mindestanforderungen reicht aus, um von der Ausführbarkeit des Programms zu überzeugen. Im nächsten Schritt folgt ein Aufruf von wget, der das Paket herunterlädt:
pi@raspberrypi:~ $ wget https://github.com/renaissance-benchmarks/renaissance/releases/download/v0.14.0/renaissance-gpl-0.14.0.jar...
Die eigentliche Ausführung der in Renaissance enthaltenen Benchmarks lässt sich dann nach folgendem Schema anweisen. Der Parameter -r 1 sorgt dafür, dass jeder Testlauf nur einmal durchläuft. Das Anliefern von all sorgt seinerseits dafür, dass „alle“ in der .jar-Datei befindlichen Jobs zur Ausführung gelangen:
pi@raspberrypi:~ $ java -jar 'renaissance-gpl-0.14.0.jar' -r 1 all====== scrabble (functional) [default], iteration 0 started ======GC before operation: completed in 1100.494 ms, heap usage 93.916 MB -> 75.568 MB.====== scrabble (functional) [default], iteration 0 completed (198623.547 ms) ======
In der Praxis schlägt dies aufgrund von fehlendem Speicher fehl. Abbildung 8 zeigt die Fehlermeldung, die bei aktiviertem GUI aufscheint. Das Raspberry Pi-Konfigurationsprogramm erlaubt das Abschalten des GUI. Die Ausführung auf SSH-Ebene schlägt allerdings ebenfalls fehl, nun mit der in Abbildung 9 gezeigten Meldung.
Zur „Lösung“ des Problems empfiehlt es sich, im ersten Schritt nach folgendem Schema eine „Liste“ aller Benchmarks zu ermitteln:
pi@raspberrypi:~ $ java -jar 'renaissance-gpl-0.14.0.jar' --list
In Tests des Autors funktionierten die folgenden fünf Benchmarks besonders gut:
dotty scrabble mnemonics finagle-http fj-kmeans
Interessant ist, dass das „gemeinsame“ Ausführen mehrerer unterschiedlicher Benchmarks zu Out of Memory-Fehlern führt – dies explizit auch dann, wenn eine „lineare“ Abarbeitung der Payload erfolgreich verläuft. Lohn der Mühen ist jedenfalls die in Tabelle 1 gezeigte „Verteilung“ der Ergebnisse.
Abb. 8: Die Ausführung des Renaissance-Benchmarks scheitert aufgrund von Speichermangel
Abb. 9: Auch ohne GUI reicht der Arbeitsspeicher nicht aus
Tabelle 1: Fünf Benchmarks
Fazit
Mit dem Raspberry Pi Zero 2W betreibt die Raspberry Pi Foundation „Produktpflege“. Wer mit seiner Lösung schon bisher mit 512 MB RAM auskam, bekommt nun eine neue Variante des Prozessrechners angeboten, die einen wesentlich leistungsstärkeren Hauptprozessor mitbringt, Java 11 unterstützt und bei anspruchsvollen Aufgaben nicht so schnell aus der Puste gerät.
Der „wichtigste“ Konkurrent sind – nach Ansicht des Autors – die verschiedenen Varianten des Orange Pi. In Zeiten der Chipkrise muss man an dieser Stelle allerdings vorsichtig sein. Während die Shenzhen Xunlong als „rein kommerzielles“ Unternehmen seine Preise ausschließlich durch die Marktverfügbarkeit festlegt, hat die Raspberry Pi Foundation ob der massiven Unterstützung von BroadCOM – zumindest bis zu einem gewissen Grad – die Möglichkeit, „politisch liebsamen“ Unternehmen unter die Arme zu greifen.
