Im Zuge meiner neuerlichen Experimente mit dem von mir liebevoll so genannten Trump-Board wurde ich mir wieder eines schmerzlichen Defizits dieser (und ähnlicher) Hardware bewusst: der mangelnden Geschwindigkeit beim Kopieren großer Dateien über das Netzwerk.

Die genannten Boards erreichen eine Performance von 900 Gbit/s mittels iperf gemessen - und das sowohl am internen GBit-Netzwerkanschluss wie auch mit UISB3-GBit-Ethernet.Adaptern aus der Grabbelkiste. Schaut man sich die Auslastung des Systems während einer Übertragung einer großen Datei mittels scp oder fuse-ssh jedoch an, so sieht man, dass die Geschwindigkeit nur bei mageren 30 MB pro Sekunde liegt und einer der Kerne zu 100% ausgelastet ist, während sich die anderen langweilen. Das ist natürlich weit von den theoretisch möglichen 100 MB pro Sekunde einer GBit-Verbindung entfernt.

Das ist auch einer der Gründe, warum ich meine Idee eines damit realisierten Raid-Systems nicht weiter verfolgt habe.

Man sieht hieran sehr deutlich, dass eindeutig die CPU der limitierende Faktor ist und nicht - wie man auch hätte annehmen können - die langsame als Massenspeicher benutzte SD-Karte.

Daher machte ich mich auf die Suche nach Möglichkeiten, trotz der Nutzung einer verschlüsselten Datenübertragung die Transferrate zu steigern. Experimente mit der zeitgleichen Kompression strich ich sofort - in dem beschriebenen Szenario ging es ja um Multimediadateien, die bereits optimal komprimiert sind und bei denen daher der Versuch einer Kompression während der Übertragung reine Verschwendung bedeuten würde.

Ich recherchierte statt dessen ob es irgendwie möglich wäre, SSH bzw. scp multi-threaded zu betreiben. Für jemanden, der gerne Experimente macht gibt es so etwas tatsächlich: Diese Lösung ist eine Patchsammlung für OpenSSH, die diverse Cryptoalgorithmen multi-threaded zur Verfügung stellt.

So experimentierfreudig war ich aber nicht, denn ich las in der Dokumentation auch, dass ein neuer Cryptoalgorithmus implementiert wurde, der die Klartext-Daten einfach durchleitet. Dadurch wurde ich darauf aufmerksam, dass man ja bei SSH und scp angeben kann, mit welchem Algorithmus der Kanal verschlüsselt wird.

Daraufhin sah ich mir an, welche Algorithmen zur Verfügung standen (auf beiden Seiten der Verbindung) und probierte alle, die sowohl Client wie auch Server unterstützten aus. Der Server war dabei wie folgt ausgestattet: uname -a Linux 5.15.0-53-generic SMP x86_64 GNU/Linux und ssh -V lieferte OpenSSH_8.2p1 Ubuntu-4ubuntu0.5, OpenSSL 1.1.1f 31 Mar 2020 - der Client stellte sich wie folgt dar: uname -a lieferte Linux rock64 4.4.167-1213-rockchip-ayufan-g34ae07687fce SMP aarch64 GNU/Linux und ssh -V lieferte OpenSSH_7.9p1 Debian-10+deb10u2, OpenSSL 1.1.1n 15 Mar 2022 als Ergebnis.

Die Ergebnisse gemessen mittels scp und einer 1GB großen Testdatei enthaltend eine MP4-Videodatei waren mit Standard-scp wie oben bereits angegeben 30 MB/s - mit dem schnellsten verfügbaren Algorithmus (in meinem Fall aes256-gcm@openssh.com) erreichte ich dagegen bereits 51 MB/s - eine drastische Steigerung, die zwar immer noch recht weit von der theoretisch erreichbaren maximalen Datenrate entfernt ist, jedoch bei mir den Entschluss reifen ließ, den Algorithmus auf meinem Trump-Board durch einen entsprechenden Eintrag in /etc/ssh/ssh_config als Standardeinstellung fest einzutragen.

Nach diesem erfolgreichen Ausgang des Experiments untersuchte ich das gleiche nochmals auf einem bereits etwas angejahrten Pi Version 3. Hier waren die Steigerungsraten nicht ganz so drastisch, ich konnte aber immerhin noch eine Steigerung von 16 MB/s auf 20 MG/s feststellen.

Zum Abschluss sei nochmals gewarnt: die niedrigere Komplexität und damit der niedrigere Verbrauch von Rechenzeit durch die anderen Cryptoalgorithmen geht beinahe sicher auch mit einer geringeren Stärke der Verschlüsselung einher - daher sollte man gut abwägen, ob man die Geschwindigkeitssteigerung wirklich benötigt und ob die jeweilige Einsatzumgebung sicher und vertrauenswürdig genug dafür ist!

Artikel, die hierher verlinken