Beim SATA-Anschluss hat der Hersteller jedoch geschlampt. Bei isolierten Schreib- und Lesetests mit Dd lagen die Werte noch im erwarteten Bereich. Im Zusammenspiel mit Netzwerkverkehr bricht die Leistung dann aber drastisch ein. Stabilitätsprobleme treten jedoch nicht auf, insbesondere die Stromversorgung über den integrierten 5V-Anschluss bereitet auch beim Betrieb einer 2,5-Zoll-Festplatte keine Probleme (Abbildung 2).
Abbildung 2: Praktisch: Unter dem Board bietet das Gehäuse noch Platz für eine Festplatte.
Cubietruck verfügt zwar über einen 12V-Anschluss für die Festplatte, der erweist sich aber als weder notwendig noch funktional. Für 3,5-Zoll-Platten bietet der Hersteller eine kleine Zusatzplatine an, die den dafür notwendigen 12V-Anschluss bereitstellt und den Cubietruck gleich mitversorgt.
Ähnlich wie beim SATA-Port sieht es mit der Performance des Gigabit-Netzwerkanschlusses aus, der seinem Namen im Cubietruck nicht gerecht wird. Die rohe Netzwerkperformance lässt sich mittels des Werkzeugs Iperf aus dem gleichnamigen Paket ermitteln.
Auf dem Cubietruck mit iperf -s als Empfänger und auf einem anderen Rechner mit iperf -c Cubietruck-IP -f M als Sender gestartet, misst das Tool einen Durchsatz von um die 550 Mbit/s – das entspricht mageren 68 MByte/s. Umgekehrt sind es ungefähr zehn Prozent weniger. Das entspricht nur etwas mehr als der Hälfte dessen, was ein Gigabit-Anschluss zu leisten imstande wäre – nicht berauschend, aber immer noch deutlich besser als die Werte auf dem RasPi: Der reizt seinen Ethernet-Anschluss zwar mit 90 Mbit/s bis zur Grenze des technisch Möglichen aus, aber das GB-Ethernet des Cubietruck erweist sich immer noch um den Faktor fünf schneller als das Fast-Ethernet des RasPi.
In der Praxis
Mehr als synthetische Messwerte zählen naturgemäß konkrete Anwendungsfälle. Die Daten, die ein schnelles Netzwerk anliefert, gilt es auf einem Server auch zu verarbeiten und zu speichern. Hier zeigt sich die eigentliche Problematik des Cubietruck: Dessen Netzwerkdurchsatz hängt extrem von der CPU-Last ab.
Insbesondere In- und Output über den SATA-Anschluss behindern den Netzwerkverkehr. In realen Szenarien erweist sich zum Beispiel ein FTP-Transfer auf eine USB-Festplatte mit 30 MByte/s als deutlich schneller als derselbe Transfer auf eine angeschlossene SATA-Platte, die nur 21 MByte/s erreicht. Nur beim Speichern der Daten in einer RAM-Disk erreicht der Cubietruck eine Übertragungsgeschwindigkeit von etwa 60 MByte/s.
Verschlüsselte Transfers mit Rsync oder Scp belasten die CPU zusätzlich: Hier sinkt die Transferrate beim Speichern auf jedes Medium. Beim Cubietruck führt das dazu, dass von den rohen 60 MByte/s dann nur noch um die 8 MByte/s übrig bleiben – und das, obwohl die CPUs nicht einmal bis zur Grenze ausgelastet wurden. Damit liegt der Wert zwar immer noch über dem des RasPi, der in dieser Disziplin gerade einmal 5 MByte/s erreicht. Ob sich der Aufpreis für den Cubietruck angesichts der geringen Steigerung lohnt, muss jeder selbst beurteilen.
Es stellt sich die Frage, wie es zu diesem Performance-Einbruch kommt. Liegt es an nicht gut aufeinander abgestimmter Hardware oder handelt es sich eher um Treiberprobleme? Da der Banana Pi eine ähnliche Hardwareausstattung mitbringt, verwendeten wir ihn für eine Vergleichsmessung. Die Ergebnisse finden Sie im Kasten “Messungen am Banana Pi”.
Messungen am Banana Pi
Da der Banana Pi auf der SoC-Seite eine ähnliche Ausstattung mitbringt wie der Cubietruck, eignet er sich beinahe perfekt, um dem ernüchternden Ergebnis der I/O-Performance-Messung auf den Grund zu gehen.
Die erste Hürde bei den Messungen bestand darin, den Banana Pi überhaupt mit angeschlossener Festplatte zu starten. Da alle verfügbaren Netzteile an dieser Aufgabe scheiterten, musste der Cubietruck Starthilfe leisten: Die 5V-Speisung der Platte lieferte also der Cubietruck, der SATA-Stecker kam an die Bananen-Platine. Offensichtlich fällt das Strom- und Spannungsmanagement des Banana Pi nicht so robust aus wie jenes des Cubietruck.
Bei den Messwerten selbst zeigte sich der Banana Pi dem Cubietruck sowohl hinsichtlich der synthetischen Messwerte überlegen als auch bei praktischen Beispielen. Insbesondere beim Schreibzugriff erreichte er eine bis zu 50 Prozent höhere Leistung, beim Lesezugriff unterschied er sich nicht so stark.
Die Unterschiede sollte man nicht überbewerten: Hier könnte es sich um Serienschwankungen handeln oder auch um unterschiedliche Optimierungen der Betriebssysteme (auf dem Banana Pi lief OpenSuse). Allerdings bleibt die Erkenntnis, dass das A20-Design offensichtlich nicht für hohe I/O-Leistungen optimiert wurde.
Gas geben
Mit etwas Tuning lässt sich die I/O-Performance zumindest in einigen Szenarien deutlich erhöhen. Der Trick besteht darin, das I/O auf der Platte hinauszuzögern und damit den Netzwerk- vom Festplatten-Datenverkehr zu entkoppeln. Das funktioniert bei einem Server, der ständig unter Last steht, sicherlich nur bedingt. Einen Cubietruck im Heimnetz erwarten jedoch in der Regel nur kurze Lastspitzen, gefolgt von Ruhepausen.
Zum Glück bringt der Cubietruck sehr viel Speicher mit. Da ARM-Programme sehr klein ausfallen, bleibt viel RAM für den Plattencache übrig. Linux geht damit üblicherweise sehr großzügig um, trotzdem gibt es hier etliche Stellschrauben, die das Verhalten im Detail beeinflussen.
Die Kommandos aus Listing 1 ändern eine ganz Reihe von Kernel-Parametern für das Caching. Wer verstehen will, was genau geschieht, sollte das Posting [6] dazu lesen; blind angewendet, können sich die Parameter auch kontraproduktiv auswirken.
Listing 1
echo cfq > /sys/block/sda/queue/scheduler echo 10000 > /sys/block/sda/queue/iosched/fifo_expire_async echo 250 > /sys/block/sda/queue/iosched/fifo_expire_sync echo 80 > /sys/block/sda/queue/iosched/slice_async echo 1 > /sys/block/sda/queue/iosched/low_latency echo 6 > /sys/block/sda/queue/iosched/quantum echo 5 > /sys/block/sda/queue/iosched/slice_async_rq echo 3 > /sys/block/sda/queue/iosched/slice_idle echo 100 > /sys/block/sda/queue/iosched/slice_sync echo 15 > /proc/sys/vm/swappiness echo 10 > /proc/sys/vm/vfs_cache_pressure echo 50 > /proc/sys/vm/dirty_ratio echo 30 > /proc/sys/vm/dirty_background_ratio echo 30000 > /proc/sys/vm/dirty_expire_centisecs echo 30000 > /proc/sys/vm/dirty_writeback_centisecs
Das zitierte Posting erklärt alle Details, hier gehen wir nur auf die letzten vier Werte ein. Die Angabe für dirty_ratio legt fest, wie viel Prozent des RAM der Kernel für den Cache nutzen darf, dirty_background_ratio setzt den Füllgrad, ab dem der Cache-Inhalt dann auf die Platte wandert. Die beiden Werte dirty_expire_centisecs und dirty_writeback_centisecs steuern die erlaubte Wartezeit für das Schreiben auf den Datenträger. Sie beeinflussen zudem den Stromverbrauch der Platte, da diese entsprechend seltener anläuft.
