Teil fünf der Serie zum Raspberry Pi als Mediacenter. Wie doch die Zeit vergeht. Neben der Hardware, Installation, und verschiedenem zur Konfiguration geht es nun um die Performance unseres Mediacenters.

Die Geschwindigkeit ist natürlich auch für ein Mediacenter eine wichtige Angelegenheit und gleichzeitig ein zweischneidiges Schwert. Denn auf der einen Seite sollen die Videos nicht ruckeln. Insbesondere bei Full HD-Videos. Gleichzeitig müssen aber auch noch ein paar Reserven vorhanden sein, um das Mediacenter flüssig bedienen zu können. Der ein oder andere Hintergrund-Task läuft zudem auch noch.

Auf der anderen Seite darf die Hardware aber nicht sonderlich hungrig nach Energie sein. Die Abfuhr der Wärme ist in einem lüfterlosen Gehäuse nicht sonderlich gut und Energie, die eingespart werden kann, ist sicherlich immer positiv zu verbuchen.

Daher geht dieser Beitrag etwas auf die Performance des Mediacenters ein und verrät den ein oder anderen Knackpunkt, an dem es recht häufig scheitert, wenn das Mediacenter nicht so flüssig reagiert wie erhofft.

Performance

Ein kritischer Punkt für ein Mediacenter ist die Performance. Auf der einen Seite ist damit gemeint, ob die Hardware leistungsstark genug ist, um alle gewünschten Medien abzuspielen. Im Falle des Raspberry Pi ist das aber der Fall. Da wir uns darum nicht mehr kümmern müssen, soll es in diesem Teil um etwas anderes gehen.

Ich möchte gerne einige Performance-Killer aufzählen, die immer wieder dafür sorgen, dass sich darüber beschwert wird, der Raspberry Pi hätte nicht genug Leistung, um als Mediacenter zu fungieren. In dieser Serie, wie im Teil 3 zur allgemeinen Konfiguration gezeigt, habe ich zwar empfohlen, die Hardware leicht zu übertakten, um einfach ein paar Reserven mehr zur Verfügung zu haben. Erforderlich ist das aber nicht. Jetzt soll es darum gehen, welche anderen Faktoren dafür sorgen können, dass die Leistung, beispielsweise beim Abspielen von Videos, nicht so gut wie gewünscht ist. Diese anderen Faktoren können so groß sein, dass auch ein bis an die Grenzen übertakteter Raspberry Pi in die Knie gezwungen wird und seine Aufgabe als Mediacenter nicht mehr gerecht werden kann.

SSH-Verbindung aufbauen

Um die Performance zu überprüfen, brauchen wir zunächst eine SSH-Verbindung. Grundsätzlich ist die Auslastung auch in den Einstellungen zu sehen. Allerdings ist das auf die Dauer doch recht aufwändig. Wer keine VNC-Verbindung einrichten möchte und das Mediacenter auch sonst nicht in Reichweite hat, sitzt immer vorm Fernseher, um sich die Auslastung anzuzeigen. Nicht sehr praktisch. Eine SSH-Verbindung macht es hier einfacher.

Eine kleine Begegnung mit SSH gab es schon einmal im Artikel zur Headless WIFI Konfiguration für den Raspberry Pi. Ich nutze als Client für die Verbindung von meinem Windows-Rechner aus gerne die Software MobaXterm anstatt beispielsweise PuTTY. Erstere hat einige Vorteile. Grundsätzlich funktioniert aber jedes Tool, mit dem eine SSH-Verbindung aufgebaut werden kann.

Eine SSH-Verbindung ist – beim Raspberry Pi – ohne größere, manuelle Konfiguration möglich. Was genau dazu notwendig ist, habe ich bereits im dritten Teil der Serie erklärt. Wenn der SSH Server beziehungsweise Dienst läuft, reicht es aus, auf dem Client einfach MobaXterm zu starten und den folgenden Befehl einzugeben.

Anschließend wird das Passwort verlangt. Wenn keine Einstellungen vorgenommen wurden, lautet das Standardpasswort raspberry für den Standardbenutzer pi. Abbildung 1 zeigt den Login-Versuch und die Ausgabe des Raspberry Pis, wenn der Login erfolgreich war. Welche IP-Adresse der Raspberry Pi hat, musste ich zuvor herausfinden. Beispielsweise über die Software eures Routers, die alle angemeldeten Geräte des Netzwerks auflistet. In meinem Netzwerk meldet sich der Pi mit dem Netzwerknamen xbmc-fb78.

Mehr ist für den SSH-Zugang an dieser Stelle nicht erforderlich. Steht die Verbindung erst einmal, können wir auf diesem Weg Befehle über die Kommandozeile an den Raspberry Pi schicken.

Ein Performance-Überblick

Um etwas über die Performance zu erfahren, brauchen wir nur ein einziges Linux-Kommando. Mittels top können wir uns ausgeben lassen, welcher Prozess gerade wie viele Ressourcen verbraucht. Mit Ressourcen sind hier beispielsweise der Arbeitsspeicher und der CPU-Verbrauch gemeint. Das folgende Listing zeigt die Ausgabe am Beispiel meines Mediacenters.

Die Ausgabe zeigt, dass aktuell nur zwei Prozesse unter dem Benutzer pi laufen, was korrekt ist. Direkt an erster Stelle steht ein Prozess, der dem Kommando xbmc.bin entsprungen ist. Dabei handelt es sich um das Mediacenter. Das top-Kommando aktualisiert im Übrigen seine Ausgabe alle drei Sekunden, so dass auch ein Verlauf der Auslastung zu sehen ist. Die CPU sollte immer zwischen 25% und maximal 50% Auslastung durch das Mediacenter liegen. Woran es genau liegt, dass die Beanspruchung nicht unter 25% sinkt, ist mir auch noch nicht ganz bewusst. Vermutlich liegt es daran, dass die Software in keinen Ruhemodus gefahren wird. Am HDMI-Ausgang liegt immer die grafische Ausgabe an, so dass bei einem Wechsel des Anschlusses sofort ein Bild zur Verfügung steht. So ist zumindest meine Beobachtung mit meinem Mediacenter. Als kleine Randnotiz: die Ausgabe oben habe ich drastisch gekürzt. Es laufen noch deutlich mehr Prozesse, die in diesem Fall aber alle nicht relevant sind.

Über 50% sollte die Auslastung im Leerlauf aber auch nicht steigen. Werte darüber sind ein gutes Anzeichen dafür, dass der Raspberry Pi mit irgendwelchen Aufgaben ausgelastet ist. Beispielsweise wenn neue Videos, Serien oder Bilder auf die externe Festplatte kopiert wurden und eine Indexierung ansteht, bei dem auch Cover heruntergeladen werden müssen.

Anhand der oben gezeigten Ausgabe wird aber schon deutlich, warum nicht noch viele weitere Prozesse ständig im Hintergrund laufen sollten. Bei einem HD-Film wird der Raspberry Pi noch mehr beansprucht. In der Regel ist das kein Problem und die Hardware kommt mit den Anforderungen ohne Probleme zurecht. Allerdings nicht, wenn noch ein weiterer Prozess 30% oder mehr der Leistung beansprucht. Und wie schnell diese 30% oder mehr erreicht sind, zeigt das folgende Beispiel.

Optionaler VNC-Server

Der VNC-Server erlaubt es, anders als SSH, eine Verbindung mit einem entfernten Rechner aufzubauen und den Bildschirminhalt zu übertragen. Wir können also die Maus steuern und direkt mit grafischen Elementen, beispielsweise einem Desktop, interagieren, als ob wir vor dem entfernten Gerät sitzen würden. Na ja, nicht wirklich ganz so gut. Etwas Verzögerung ist natürlich vorhanden.

Dieser VNC-Server kann beim Raspberry Pi direkt aktiviert werden. In Teil drei habe ich das kurz bei den allgemeinen Einstellungen zu den Diensten erwähnt. Zugegeben, dass ist sehr einfach, komfortabel und ohne viel Nachdenken erledigt. Die folgende Ausgabe des bekannten top-Kommandos zeigt, was das für Folgen hat. Auch hier ist die Ausgabe wieder drastisch gekürzt, um nicht zu viel Platz zu benötigen.

Neben dem Prozess zum Kommando xmbc.bin gibt es nun einen weiteren. Das Kommando vnc_dispmanx ist der VNC-Server, den wir aktiviert haben. Dieser verbraucht, ohne dass eine Verbindung besteht, über 46% der CPU-Ressourcen. Schwankt der Prozess des Mediacenters also, kann es durchaus sein, dass die gesamte Auslastung zwischen 80% und 95% liegt. Und das dauerhaft. Jetzt sollte klar sein, warum der Raspberry Pi Probleme bekommt, wenn jetzt noch ein Video abgespielt werden soll. Die Folge sind Bildaussetzer beziehungsweise Ruckler beim Video und auch der Ton ist alles andere als unterbrechungsfrei oder synchron mit dem Bild.

Den VNC-Server also einfach in den Einstellungen des Raspbmc zu aktivieren, scheint keine gute zu sein. Ein kleines Shell-Skript kann hier helfen, den Server einfach bei Bedarf zu starten und anschließend wieder zu stoppen. Dazu ist zunächst zwar eine SSH-Verbindung notwendig, allerdings kann ich das verschmerzen. Meine persönliche Erfahrung ist, dass ich eine VNC-Verbindung sehr, sehr selten brauche. SSH reicht vollkommen aus. Vielleicht lasse ich in zukünftigen Versionen den VNC-Server komplett weg.

Nichtsdestotrotz soll es jetzt um das besagt Skript gehen. Das habe ich auch einfach mal im folgenden Listing aufgeführt.

Ich möchte an dieser Stelle gar nicht großartig auf die Programmierung an sich eingehen, sondern lediglich zeigen, wie dieses Skript eingebunden werden kann. Obwohl eingebunden deutlich übertrieben ist. Denn viel mehr als an die richtige Stelle kopieren ist gar nicht nötig.

Das Skript kann entweder direkt mit MobaXTerm auf den Raspberry Pi oder manuell in eine Datei kopiert werden. Ersteres funktioniert sehr gut die sogenannte SFTP-Funktion. Nach dem Anmelden ist auf der linken Seite eine Verzeichnissstruktur abgebildet. Dort kann einfach eine Datei mittels Drag & Drop abgelegt werden. Ebendiese Datei wird dann auf den Raspberry Pi kopiert. Und zwar genau dort hin, wo wir uns gerade, also nach dem Login, befinden. Manuell geht es am einfachsten über einen Texteditor. Also beispielsweise durch das Kommando:

nano vncserver

Damit wird eine Datei Namens vncserver angelegt und mit dem Programm nano geöffnet. Dort bitte das Skript rein kopieren. Entweder über das Kontextmenü der Maus oder über die Tastenkombination SHIFT + INSERT. Anschließend die Datei mit STRG + W speichert und mit STRG + X schließen. Egal welchen Weg wir nehmen, jetzt gibt es eine neue Datei im Home-Verzeichnis unseres Raspberry Pis. Als Dateinamen empfehle ich vncserver. Ein anderer geht aber auch. Eine Endung ist nicht erforderlich.

Nun muss das Skript noch als ausführbar gekennzeichnet werden, was über das folgende Kommando möglich ist:

chmod +x vncserver

Zum Schluss braucht das Skript noch einen neuen Speicherort. Das nächste Kommando kopiert die Datei an die richtige Stelle:

sudo mv vncserver /usr/local/sbin

Genau genommen wird die Datei an diese Stelle verschoben. Denn im Home-Verzeichnis brauchen wir sie nicht mehr. Nachdem wir diese Schritte ausgeführt haben, kann der Server manuell über die Kommandozeile gestartet und gestoppt werden. Das erledigen die folgenden beiden Kommandos:

vncserver start oder vncserver stop

Damit ist auch das Problem erledigt, dass der VNC-Server immer im Hintergrund läuft und ständig sehr viele Ressourcen an sich bindet. Damit ist der VNC-Server optional und nicht immer ständig vorhanden. Ob VNC überhaupt notwendig ist, muss jeder für sich entscheiden. Ich benutze es in letzter Zeit sehr selten. SSH reicht für meine Zwecke aus.

Zwischenfazit

Dieser fünfte Teil der Serie befasste sich mit einigen Performance-Aspekten. Allerdings ist das nur eine sehr kleine Auswahl, die zeigen sollte, dass ein Dienst, der im Hintergrund läuft, sehr viele Ressourcen binden kann. Das ist insbesondere dann ärgerlich, wenn dieser Dienst gar nicht oft benötigt wird. Zwischenzeitlich kann es nützlich sein, mal mit dem top-Kommando nachzuschauen, ob der Raspberry Pi unter größerer Last steht.

Das Thema Performance sollte aber nur ein Thema sein, wenn es zu Problemen kommt. Wenn beispielsweise Videos ruckeln oder das Gehäuse des Raspberry Pis deutlich wärmer wird als handwarm. Vorher würde ich mir keine großen Sorgen machen.

Im kommenden Teil 5 geht es um ein paar Tipps & Tricks, die das Leben mit dem Raspberry Pi beziehungsweise Raspbmc einfacher machen können. Wir kümmern uns auch um das Abspielen von MPEG-2- und VC-1-Videos, die von unserem Mediacenter aktuell noch nicht verstanden werden.