© Konstantin Sutyagin, 123RF

Für ein Kundenprojekt benötigte der Autor ein Messgerät, das auch mit Gigabit-Netzen zurechtkommt. Als überraschend kostengünstige und effiziente Zugmaschine fährt der Scheckkarten-PC Cubietruck.

Wer an einer Netzwerkinfrastruktur mitentwickelt, in der auch LTE-Verbindungen zum Einsatz kommen, stößt schnell an Grenzen. Im vorliegenden Beispiel, einem Kundenprojekt, an dem der Autor dieses Artikels mitwirkte, gehörten zu den Testfällen auch Durchsatz-Tests. Weil aber die LTE-Technologie Bandbreiten von über 100 MBit/s ermöglicht, schied das Macbook Air des Autors aus, weil es nur einen 100-MBit-USB-Ethernet-Adapter vorweisen kann.

Wenn der Pi nicht reicht

Auch die verschiedenen Raspberry-Pi-Ausgaben reichen mit ihren 100-MBit-Schnittstellen nicht aus – eine preisgünstige Alternative musste her, auf der Linux läuft. Inspiriert durch diverse Artikel im Linux-Magazin [1] fiel die Wahl schließlich auf einen Cubietruck ([2], Abbildung 1).

Abbildung 1: Scheckkartengroß wie der Raspberry Pi, aber deutlich leistungsfähiger: der Cubietruck.

Neben dem Cubieboard aus dem Artikel kam noch das Wandboard ([3], Abbildung 2) in die engere Auswahl. Beide Scheckkarten-PCs gibt es mittlerweile in neueren Versionen: Der Cubietruck ist die dritte Generation der Cubie-Familie [4], auch vom Wandboard sind Versionen mit mehr CPU (Leistung und Cores) und mehr RAM im Angebot, beide Boards beherrschen Gigabit-Ethernet. Weil kein Händler das Wandboard verfügbar hatte, fiel die Entscheidung für den Cubietruck.

Abbildung 2: Auch das Wandboard (das englische “Wand” bedeutet “Zauberstab”) käme für das Projekt in Betracht, doch war es nicht verfügbar.

Die Hardware

Abbildung 3 zeigt das Paket des Cubietruck: Das Board hat auf der CPU einen kleinen Kühlkörper, separat dazu kommen das SATA-Kabel zur Versorgung von Festplatten, die Micro-SD-Karte sowie das eigens für wenige Euro bestellte Gehäuse für den Einsatz unterwegs und das Konsolen-Kabel, das sich bei den Experimenten mit selbst gebauten Kerneln als sehr wertvoll erwies.

Abbildung 3: Links im Bild die Platine des Cubietruck, davor liegt die Micro-SD-Karte, dahinter SATA- und Konsolenkabel, rechts das zusätzliche Gehäuse.

Da der Cubietruck 4 GByte eingebauten NAND-Speicher besitzt, ist die Speicherkarte eigentlich nicht notwendig, aber gerade bei der Netzwerküberwachung hilfreich. Auch sind heutzutage 4 GByte weder viel noch teuer und der eingebaute NAND-Speicher ist vergleichsweise langsam.

Das System bietet zwei USB-2.0-, einen HDMI- sowie digital-optische und analoge Audio-Anschlüsse sowie einen VGA-Port. Dazu kommen Infrarot-Empfänger, ein OTG-Anschluss, der auch zur Stromversorgung dienen kann, Bluetooth 4.0 sowie ein 802.11b/g-WLAN-Anschluss. Die 2 GByte RAM und eine Dual-Core-Allwinner-A20-CPU, die mit maximal 1 GHz läuft, sorgen für ausreichend Power. Schließlich bietet das Board noch frei programmierbare GPIO-Pins sowie einen UART-Port, für den aber ein TTL-Kabel notwendig ist.

Leistungsvergleich

Um einen Eindruck der Leistungsfähigkeit der CPU im Vergleich zu einem Pi zu bekommen, experimentierte der Autor ein wenig mit dem Kommando »openssl speed« , das Benchmarks für alle möglichen Verschlüsselungs- und Hash-Algorithmen bietet. Mit dem Parameter »rsa1024« erzeugt es 1024-Bit-RSA-Key-Signaturen und prüft sie.

Dabei schaffte der Cubie 158 Signaturen in der Sekunde und 2800 Verifies. Der Pi im Vergleich dazu nur 120 Signaturen und 2010 Verifies. Der Unterschied ist umso deutlicher, als der Cubie dazu nur einen Core benutzte. Ein Test, der das Kommando zweimal gleichzeitig aufrief, brachte dann auch eine Verdopplung dieser Werte.

Bei SHA1-Hashes schaffte es der Cubie bei 16 Byte Eingabe, knapp 5000 KByte/s zu hashen – im Vergleich zu 2300 auf dem Pi. Je größer der Input, desto kleiner wird allerdings der Unterschied: Bei 8192 Byte schaffte der Cubie 48000 KByte/s im Vergleich zu 40000 KByte/s auf dem Pi. Aber auch hier benutzte der Cubie nur einen Core

Installation

Die Erstinstallation auf dem internen NAND-Speicher erfolgt mit Hilfe eines Werkzeugs namens Phoenixsuite [5] über das OTG-Kabel. Der angehende Cubietrucker muss einfach beim Aktivieren der Stromversorgung einen Knopf am Board gedrückt halten, damit es im FEL-Modus bootet. Dabei bietet sich der NAND-Speicher gewissermaßen als USB-Festplatte an, sodass das Image auf der Karte landet.

Kommt eine SD-Karte für das Betriebssystem zum Einsatz, kann der Admin diese wie beim Pi über einen entsprechenden Reader auf einem Rechner mit Dd beschreiben. In der Default-Bootreihenfolge versucht der Cubietruck zunächst den SD-Card-Slot und dann erst den NAND-Speicher.

Für die Tests diente Arch Linux, wobei der Cubietruck nach dem Initialisieren der Hardware im ersten Schritt eine angepasste Version des Uboot-Bootloaders startet. Dieser bietet über die serielle Konsole die Möglichkeit, den Bootprozess zu unterbrechen, sodass der Admin zum Beispiel andere Kernel-Versionen oder -Parameter setzen kann.

Die Linux-Entwicklung für die Allwinner-CPUs hinkt leider der aktuellen Kernelentwicklung hinterher. Arch Linux verwendet den Baum, der unter [6] entwickelt wird. Die letzte Version in der Distribution ist 3.4.90. Einige Versuche, selbst einen Kernel zu bauen, führten zwar zu einem bootenden System, aber ein funktionierendes Ethernet-Interface war mit aktuellen Kerneln nicht zu erreichen.

Der Autor kam jedoch wegen eines Fehlers in der Standardkonfiguration des Arch-Distributionskernels in die Verlegenheit, doch eine Config-Option ändern zu müssen. Hierzu musste er dann das Arch-Buildsystem verwenden und die Kernelkonfiguration, die bei den Sourcen mitkommt, händisch anpassen. Geeignete Arch-Builds erhält der Administrator über »git clone https://github.com/archlinuxarm/PKGBUILDs« .

Bluetooth

Der Cubietruck besitzt auch ein Bluetooth-4.0-Interface, dessen Aktivierung allerdings nicht so ganz trivial ist. Das Interface erscheint zunächst als UART, also als serielle Schnittstelle. Im Arch-Linux-Kernel war ab einer Zwischenversion aber nur eine Schnittstelle konfiguriert, weshalb der Autor den Kernel erst aus den Distributionsquellen selber bauen musste (siehe Kasten “Bluetooth auf dem Cubietruck”).

./brcm_patchram_plus -d --patchram /lib/firmware/ap6210/bcm20710a1.hcd --enable_hci --bd_addr 11:22:33:44:55:66 --no2bytes --tosleep 1000 /dev/ttyS1

Zum Messen des Durchsatzes auf Layer 3 und 4 stehen natürlich keine Performance-Tester wie die von Ixia oder Spirent zur Verfügung. Stattdessen greift der Linux-Admin gerne zu Open-Source-Paketen wie Netperf [8] oder Iperf [9].

Der Cubie als Messgerät

Beide bestehen aus einer Server- und einer Client-Komponente, bei der der Client eine Verbindung zum Server aufbaut, Pakete sendet und dabei misst, wie viele Pakete erfolgreich auf der anderen Seite ankommen. Dabei ist Netperf etwas mächtiger, da es neben Tests für die erzielte Bandbreite auch die Verbindungsaufbauten pro Sekunde misst und sogar SCTP-Support anbietet.

Die wichtigsten Parameter bei der Messung sind die erzielbare Bandbreite bei großen Paketen, aber eben auch (häufig vernachlässigt) die Menge der Pakete pro Sekunde. Bei Firewalls als Testobjekt ist auch die Verbindungsaufbaurate recht wichtig, da eine Firewall ja für jede neue Verbindung diverse Einträge in den Verbindungstabellen vornehmen muss.

Durchsatz

Bei den Durchsatz-Tests mit dem Cubietruck als Sender oder Empfänger hat Netperf enttäuscht, mehr als 30 MBit/s ließen sich nicht erzielen. Mit Iperf sah die Situation allerdings schon anders aus. Der Cubietruck als Sender erzielte bis zu 550 MBit/s, als Empfänger sogar 850. Im Vergleich erreicht ein Raspberry Pi mit Iperf knapp 70 MBit/s.

Um die maximale Anzahl der Pakete herauszufinden, muss der Tester die Parameter Paketgröße und Gesamtbandbreite entsprechend abstimmen. Der Server muss mit der Option »-u« auf UDP eingestellt sein. Deswegen gehen irgendwann Pakete verloren, sodass der maximal erreichbare Wert der ist, bei dem keine oder nur sehr wenige Pakete verloren gehen. Die Parameter auf Client-Seite sind »-b Bandbreite« und »-l Paketlänge« .

Hier erreichte der Cubietruck im Maximum 55 000 Pakete pro Sekunde. Zum Vergleich: Ein Lenovo-Notebook mit einem Intel-Core-Duo bei 2 GHz schafft etwa 169 000, ein Raspberry Pi knapp 8000 Pakete pro Sekunde.

Eine Besonderheit fällt im Zuge der Tests auf: Hat der Admin den Cubietruck für ein Tagged VLAN konfiguriert, dann sinkt der Durchsatz ins Bodenlose. Im Output von »dmesg« finden sich dann Meldungen der Art »GMAC TX status: VLAN frame« , sodass zu vermuten ist, dass der Treiber es mit Offloading probiert, dies aber nicht effizient löst. In einem solchen Szenario sollte der Tester dem Switch das Tagging überlassen.

Andere Tests laufen gegen Webapplikationen. Einer der schnellsten Scanner ist Skipfish [10]. Er eignet es sich auch dazu, die Performance von Webservern oder deren Komponenten wie den Web-Application-Firewalls zu testen, da Skipfish während des Laufs auch Informationen über die HTTP-Anfragen pro Sekunde ausgibt.

Preis und Leistung passen

Der Cubietruck erzielte in einem Lauf gegen einen Apache ohne HTML-Daten mehr als 2000 Requests pro Sekunde, was meist mehr als ausreichend ist. Dabei ist das Gerät auch sehr energiesparend, da die CPU im On-Demand-Governor-Modus bis auf 60 MHz herunterregeln kann. Bei normalen Webapplikations-Tests ist das Testwerkzeug die meiste Zeit mit Warten beschäftigt, was zu einer guten Energiebilanz des Tests führt, ohne Performance-Einbußen auszulösen.

Der Cubietruck ist für unter 100 Euro brutto zwar etwa doppelt so teuer wie ein Raspberry Pi, aber in der Praxis deutlich leistungsfähiger. Als Manko erweist sich der Kernelsupport, der noch nicht auf dem letzten Stand ist, was sich aber hoffentlich in Zukunft bessern wird.

Für den Preis bekommt der Käufer ein Gerät, das prima in die Tasche passt, auch im Serverbetrieb universell einsetzbar ist und sich dank der Möglichkeit einer seriellen Konsole auch gut headless betreiben lässt. Die zwei schnurlosen Schnittstellen runden das Bild für Infrastruktur-Audits ab.