IBM T41 mit SATA-SSD ist langsam?

Wer eine SSD in ein IBM T41 nachrüstet – z.B. in so einem SATA-Ultrabay-Adapter* – könnte folgendes Problem haben: aufgrund der internen Konversion von SATA auf PATA im T41 läuft die SSD eh schon langsam. Und dann kommt raus, dass die echt nur so 30 MB/s bringt. Woran liegt das? Im Output von ‚dmesg‘ findet sich:

ata2.00: limited to UDMA/33 due to 40-wire cable ata2.00: configured for UDMA/33

Das Problem ist u.A. im Thinkwiki dokumentiert.

Die Lösung

Um den Treiber zu zwingen, schnellere DMA-Modi zu benutzen, kann dem Linux-Kernel folgendes Flag mitgegeben werden:

libata.force=80c

Diese Info habe ich im Fedora-Forum gefunden.

Der Test

Vorher:

# hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads: 852 MB in 2.00 seconds = 425.66 MB/sec
 Timing buffered disk reads: 92 MB in 3.06 seconds = 30.11 MB/sec

Nachher:

# hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads: 902 MB in 2.00 seconds = 450.35 MB/sec
 Timing buffered disk reads: 234 MB in 3.00 seconds = 77.91 MB/sec

 

*) keine Werbung – aber der funktioniert!

Minimales Debian für Raspberry Pi

Wer (wie ich) den Raspberry Pi eher für embedded-Zeug einsetzt und Debian als Basis mag, wird mit der offiziellen Raspbian-Distribution oft nicht so glücklich: sie bringt, aus der Motivation, ein Lernsystem bereit zu stellen, viel zu viel überflüssige Software wie u.A. einen kompletten Desktop mit.

Bisher habe ich mir immer damit beholfen, den überflüssigen Kram händisch zu identifizieren und die Pakete zu entfernen, aber das kostet Zeit und klappt dann auch nicht zwangsläufig vollständig. Besser wäre es, nicht benötigte Komponenten gar nicht erst im Installationsimage zu haben. Und da ist mir (jetzt erst) ein praktisches Projekt aufgefallen: MINIBIAN. Dieses Installationsimage ist weiterhin Raspbian, aber entsprechend von Haus aus stark gestrippt. Bringt nur alles mit um die Kiste hochzubringen und startet SSHd. Alles weitere kann dann hinzugefügt werden soweit gebraucht. Tolle Sache!

Aus den Features:

  • Raspbian “Jessie” based
  • Kernel 4.1.7+ #817
  • 14 secs boot (on RPi 2B)
  • 29 MB RAM used
  • 451 MB disk space used
  • Fit on 1GB SD Card
  • Optimized ext4 file system with swap disabled
  • Support for RPi B, RPi B+ and the new RPi 2B
  • Targeted for embedded or server applications (NAS, Web server, electronic applications)
  • 100% full compatbile with official release
  • DHCP client enabled
  • SSHD enabled

Hier geht’s zum aktuellen Release:
https://minibianpi.wordpress.com/2015/11/12/minibian-jessie-2015-11-12-is-out/

Raspberry Pi als transkodierender Streamingserver

Kurz: hier wird erklärt, wie aus dem Raspberry Pi mit einfachen Mitteln ein in Hardware transkodierender UPnP-Streamingserver gebaut werden kann.

Um zu erklären, warum ich das ganze Thema überhaupt angefasst habe, muss ich ein bisschen ausholen. Bei uns in der WG verdient sich eine alte XBOX der ersten Generation ihr Gnadenbrot als Mediaplayer im Wohnzimmer. Kann zwar kein HD, dafür aber dank der emsigen Entwickler von XBMC4XBOX nach wie vor eine große Palette an Formaten abspielen und z.B. per Emulator alte Spiele wieder zum Leben erwecken. Wo ist das Problem? Die XBOX hat nur 733 MHz und 64MB RAM, dementsprechend schwer tut sie sich mit hochauflösenden Videos, zum Beispiel Aufzeichnungen oder Sendungen aus den Mediatheken. Natürlich wäre es möglich, diese Files jeweils einzeln in passende Formate „herunterzurechnen“, allerdings ist das zeitaufwändig und zerstört die Möglichkeit, auf anderen Abspielgeräten die HD-Formate in voller Qualität anzusehen.

Was also tun? Da ich ohnehin als Testplattform für diverse Projektbasteleien einen Raspberry Pi Model B hier im Einsatz habe, lag die Idee nahe, diesen etwas zweckentfremdet in Gebrauch zu nehmen (ohne, dass er an den Fernseher angeschlossen werden muss, wie zum Beispiel mit RaspBMC oder OpenELEC möglich).  Der Raspberry bietet die Möglichkeit, hardwarebasiert MPEG2, MPEG4 und H.264 zu decodieren. Außerdem kann er auf dem Chip H.264 encodieren. Die Idee ist geboren: der Raspberry soll im Netzwerk liegende Videofiles live in einen geringer aufgelösten H.264-Stream transkodieren und per UPnP an die XBOX (und andere schwachbrüstige Clients) ausliefern.

Benötigte Software:

  • installiertes Linux-System auf dem Raspberry, z.B. Raspbian
  • mediatomb UPnP-Server
  • build-Umgebung, um omxtx zu kompilieren

Als Besonderheit kommt für die ganze Aktion das tool omxtx zum Einsatz. Es dient dazu, auf dem Raspberry das Transkodieren direkt auf dem Chip durchzuführen, was gegenüber den Lösungen mit GStreamer den Vorteil hat, zwei Pipelines einzusparen und damit deutlich ressourcenschonender zu sein. Es ist experimentelle Software, die vielleicht noch nicht perfekt funktioniert, der aktuelle Stand genügt jedoch bereits für einen versuchsweisen Einsatz.

Folgende Schritte sind erforderlich (bitte seht mir nach, dass ich das nicht bis ins kleinste Detail ausführe. Bei Unklarheiten bitte die Dokumentation, Suchmaschine oder Kommentarfunktion benutzen!):

  1. omxtx anpassen und kompilieren
  2. mediatomb konfigurieren

omxtx anpassen und kompilieren

omxtx-Source mit Git auf den Raspberry (muss unbedingt dort kompiliert werden, da ARM-Architektur!) klonen. Nun müssen wir im Quelltext eine Änderung machen, damit das ganze mit mediatomb zusammen spielt. Warum? Mediatomb nutzt fifos für die Übergabe der Daten an das Tool, welches zum Transkodieren genutzt wird. omxtx kann aber anhand des (fest in mediatomb gesetzten bzw. automatisch generierten) fifo-Dateinamens nicht erkennen, welches Ausgabeformat wir haben wollen; default wäre MPEG2. Als am stabilsten für die XBOX hat sich der mkv-Container erwiesen, also sorgen wir dafür, dass omxtx im Zweifelsfall (also dann, wenn der Dateiname der Zieldatei keine erkennbare Endung besitzt; so beim von mediatomb übergebenen fifo der Fall) automatisch mkv erzeugt.

Folgende Zeilen in der omxtx.c suchen…

if (!fmt) {
 fprintf(stderr, "Can't guess format for %s; defaulting to "MPEG\n", oname);
 fmt = av_guess_format(NULL, "MPEG", NULL);
 }

…und ersetzen:

if (!fmt) {
 fprintf(stderr, "Can't guess format for %s; defaulting to "MKV\n", oname);
 fmt = av_guess_format("matroska", NULL, NULL);
 }

Nun mittels make das binary erzeugen und z.B. nach /usr/bin ablegen.

mediatomb-Konfiguration

Mediatomb am besten erstmal ohne transcoding komplett konfigurieren und Quellen hinzufügen (siehe mediatomb-Dokumentation). Wenn alles läuft, transcoding einrichten, z.B. mit Inspiration aus dem mediatomb-wiki.

Damit omxtx genutzt werden kann, muss in der Konfigurationsdatei von mediatomb im Abschnitt transcoding ein neues Profil angelegt werden, das wie folgt aussehen könnte:

<profile name="openmax" enabled="yes" type="external">
 <mimetype>video/x-matroska</mimetype>
 <accept-url>yes</accept-url>
 <first-resource>yes</first-resource>
 <hide-original-resource>yes</hide-original-resource>
 <accept-ogg-theora>yes</accept-ogg-theora>
 <agent command="omxtx" arguments="-r 640x360 %in %out"/>
 <buffer size="1440000" chunk-size="51200" fill-size="12000"/>
 </profile>

Wie zu sehen ist, wird omxtx als externer „Agent“ zur Transkodierung benutzt, es verkleinert das Ausgangsmaterial auf 640×360 Pixel (was auf der XBOX auch bei Szenen mit hohen Datenraten flüssig läuft).

Zum Troubleshooting empfiehlt sich VLC, da dieser Player einen UPnP-Client enthält und umfangreiche Infos über den gelieferten Stream (Auflösung, Datenrate, Codec) liefert.

Im Screenshot zu sehen: das transcoding macht dem Raspberry nur wenig Mühe (links), der Stream wurde in h264 konvertiert (rechts)

Im Screenshot zu sehen: das transcoding macht dem Raspberry nur wenig Mühe (links), der Stream wurde in h264 konvertiert (rechts)

Da omxtx nur die Videodaten anfasst und Audio 1:1 übernimmt, läuft Ton im fertigen Stream ca. 100ms vor. Entweder am Abspielgerät korrigieren oder damit leben, mir ist gerade kein einfacher Weg bekannt, das zu fixen…


Hinweis: dieser Artikel hat es als einziger aus meinem alten Blog ins neue geschafft. Die alte URL lautete http://blog.affenterror.de/?p=783 und steht hier, damit Menschen den Artikel wieder finden können.