DevelOS Struktur

Ich habe mal ein Diagramm erstellt um die grundlegende Struktur von DevelOS aufzuzeigen.
Leider ist es im Moment nicht wirklich so lauffähig, wie ich es gerne hätte. Bei der erweiterung habe ich wohl einige inkompatibilitäten erzeugt, und die Performance lässt auch stark zu wünschen übrig. Teile des Systems werde ich wohl neu schreiben müssen. Aber die Struktur will ich gerne so belassen. Noch rot eingezeichnet ist das Konsolen-Modul. Das habe ich erst jetzt implementiert. Mir ist aufgefallen das der Zugriff auf den Buffer des Display-Moduls problematisch sein kann. Außerdem hätte ich die gesamten Ausgabe-Routinen für den UART nochmal neu schreiben müssen. Also habe ich mich entschloßen den Buffer und die Ausgabefunktionen aus dem Display-Modul heraus zu nehmen. Dieses Modul macht jetzt nur noch die Initialisierung und das Übertragen vom Konsolenbuffer in den Hardware-Puffer des jeweiligen Display Moduls. Allerdings ist da noch so einiges im argen. Ich glaube ich habe da noch jede Menge Speicherlöcher drin.

DevelOS Struktur

Wie man hier sieht belegt DevelOS selbst einen großen Teil der externen Schnittstellen des PIC. Es verwaltet den Taktgenerator, die AD Wandler und das EEProm. Über IO-Pins können weitere Geräte angebunden werden.

Freestyle-I2C

Im Moment habe ich an meiner Testplatine ein 4x20 Zeichen LCD Display angeschloßen, sowie zwei kleine I2C-EEproms. Eines ist ein Atmel 32kbit-EEPROM das nur eine Bus-Adresse hat, aber intern mit 16bit Adressen arbeitet. Das andere ist ein ST 8kbit, das intern mit 8 bit adressiert wird, dafür aber in 4 Bänke unterteilt ist, die jeweils über eigene Bus-Adressen angesprochen werden. Eine gute Möglichkeit, um einen wirklich universellen Treiber zu schreiben, der beide EEPROMs ansprechen und für das DevelOS einheitlich darstellen kann. Sie sind zwar etwas abenteuerlich angeschloßen, aber im Prinzip funktioniert es. Den UART habe ich auf eine Buchse heraus geführt, aber bisher funktioniert er nicht richtig. Da der PIC im Moment nur mit dem internen Oszillator läuft, ist die Baudrate wohl zu ungenau. Die Buchse habe ich von einem alten Mainboard geerntet. Eigentlich ist es ein Audio-Anschluß für ein CD oder DVD Laufwerk. Die drei belegten Pins machen ihn aber für alles mögliche einsetzbar, und die etwas besseren Kabel für diesen Port sind sogar abgeschirmt. Damit will ich später mal die

Verbindung von diesem PIC-Board zu meinem Server herstellen. Auf dem Bild hier links sieht man das Display, und die zwei Ports die ich eben beschrieben habe. Der linke, schwarze davon ist an den UART angeschloßen, der andere ist noch nicht belegt. geplant hatte ich dort den I2C-Bus heraus zu führen, um zusätzliche Chips mit anbinden zu können. Ganz am linken Rand sieht man oben den Anschlußblock für die Stromversorgung und den Anschluß der Lüfter, die der PIC einmal regeln soll. Die Stiftleiste rechts neben den Widerständen ist ein Anschluß für die Spannungen des ATX-Netzteils. Diese soll der PIC ebenfalls überwachen und dem Banana Pi über den UART mitteilen. Unter dem Anschlußblock links sieht man auch noch zwei Transistoren die ich ebenfalls von alten Mainboard habe. Für die Steuerung von Lüftern sind sie mit einer Schaltleistung von über 100 Ampere zwar völlig überdimensioniert, aber hey, was nichts kostet ist auch nicht verschwendet.


Zwischen dem Anschlußblock und dem Kabel für das Display sieht man noch den Anschluß für das Programmiergerät. Dafür verwende ich eine ehemalige PS2-Buchse. Ich wollte mein Programmiergerät nicht jedes mal wieder an eine Stiftleiste anschließen, sondern eine komfortable Möglichkeit haben ein Gerät auch von außen zu Programmieren.

Der weitere Ausbau gestaltet sich jedoch schwierig, da das Programm jetzt nur noch etwas mehr als 100 mal pro Sekunde durch läuft. Dabei wird aber schon zwei mal das Display neu geschrieben und einige Timer laufen. Es kann jedoch noch einiges optimiert werden. Zum Beispiel wird die Uhr im Moment von einem 8-bit Timer abgeleitet mithilfe eines Software-Zählers. Das ist extrem ineffizient. es wäre deutlich besser hierfür einen 16-bit Timer mit entsprechenden Preloadwerten zu verwenden.Und wenn ich mir die Zeit nehme, finde ich bestimmt noch hundert weitere Möglichkeiten zur Optimierung. Leider habe ich das Profiler-Plugin für MPLab-X nicht, und will auch keine 45 Euro dafür bezahlen. Also werde ich wohl so zurecht kommen müssen.

Hier nochmal ein Link zum Projekt auf Github: https://github.com/Stefanie80/DevelOS.X/tree/experimental

DevelOS auf github

Ich habe mein DevelOS jetzt auf github veröffentlicht.
Am Anfang war es noch etwas gewöhnungsbedürftig, aber ich hab die Bedienung hin bekommen.

Leider läuft das System so wie es gerade ist nicht richtig. Vermutlich wird irgendwo eine Variable überschritten oder so, aber das habe ich auf die schnelle nicht gefunden. Es tritt interessanter Weise nur im production Image auf, das Debug Image läuft gut.

Die Sources sind hier zu finden: https://github.com/Stefanie80/DevelOS.X

Hoffe das es noch jemandem was bringt ...

Download-Server im Einsatz

Ich hatte ja schon angekündigt, das ich in absehbarer Zeit ein Howto erstellen will, wie man einen Homeserver selbst konfiguriert. Dafür werde ich dann natürlich meinen vorhandenen Banana Pi einsetzen. Aber noch ist es nicht so weit. Ich habe den Server ja erst kürzlich zerlegt, und bevor ich das nochmal mache, möchte ich ein bisschen was vorbereiten. Auf jeden Fall will ich dann gleich das aktuellste Betriebssystem verwenden, und die Einrichtung dann Schritt für Schritt dokumentieren. Und auch an der Hardware will ich noch ein bisschen was verändern. Heute soll es aber erstmal um die Vorbereitung gehen. Und dabei kann ich auch gleich zeigen, wie und wofür man so einen Server sehr gut einsetzen kann. Einer der wichtigsten Punkte ist für mich die Downloadverwaltung. Und die wird heute zum Einsatz kommen.Die aktuellste Version von Bananian gibt es hier: https://www.bananian.org/download

Im Moment ist das Debian 8 Jessie. Die Datei ist zwar "nur" 158 MB groß, das wäre noch an der Grenze dessen was ich lokal auf dem Desktop runter laden würde. Aber heute mache ich es gleich über Torrent, um den Vorgang mal zu zeigen.
Wie man auf dem Screenshot sehen kann, gibt es auf der Seite von Bananian nur einen direkten Link auf die ZIP-Datei. Man kann aber trotzdem Torrent verwenden, dafür gibt es die Seite http://burnbit.com/. Man klickt auf einen beliebigen Download-Link mit der rechten Maustaste, und wählt dann den Punkt "Link-Adresse kopieren".
Dann geht man auf die Seite von Burnbit, und fügt den Link in die Zeile oben ein.

Hier muß man ein bisschen aufpassen, denn es werden nur reine http-Links unterstüzt. In diesem Fall ist es ein https-Link, der würde so nicht funktionieren. Aber in den meisten Fällen klappt es trotzdem, wenn man das 's' einfach löscht.
So klappt es auch hier. Danach öffnet sich die Download-Seite mit einigen Infos zur Datei.
Hier finde ich den Punkt "Added:7 months ago" besonders interessant. Das heist ich bin nicht die erste, die Burnbit verwendet um diese Datei zu laden, jemand hat sie schon vor 7 Monaten hinzugefügt.

Ein klick auf "Download Torrent" startet dann den Download. Falls die Datei noch nicht bei Burnbit registriert ist, erscheint in diesem Fenster oben ein Forstschrittsbalken, während die Datei verarbeitet wird. Dabei wird sie in viele kleine Teile unterteilt und für jedes Teil wird eine Prüfsumme berechnet, so das man sie von mehreren Quellen gleichzeitig herunterladen kann, aber trotzdem die Integrität der Datei sichergestellt ist. Warum das wichtig ist, werdet ihr gleich noch sehen. Jetzt geht es aber erstmal ans runterladen:

Ich wähle hier direkt "Öffnen mit ...". Wie man sieht wird nun eine Größe von nur knapp 50kb angezeigt. Was man hier herunter lädt, ist nur eine sogenannte Metadatei. Sie enthält Prüfsummen der Datei und Angaben dazu, wo sie zu finden ist. Nach dem Klick auf OK öffnet sich Deluge mit dem Dialog zum Hinzufügen eines neuen Torrents. Hier kann man auch gleich ein paar Einstellungen vornehmen, wie zum Beispiel den Zielordner. Sobald man die Datei hinzugefügt hat, legt Deluge direkt mit dem Download los.

 Allerdings läuft der Download selbst auf dem Server, nicht auf meinem PC. Den könnte ich jetzt auch ausschalten.
Wozu der Umweg? Naja, bei dieser Datei ist die geschätzte Downoaldzeit nur gut 10 Minuten, da lohnt es sich kaum. Es sei denn man will in der Zeit etwas anderes Nebenbei machen. Deluge bietet nämlich unter anderem die Möglichkeit, die Up- und Downloadgeschwindigkeit zu bestimmen. Ich habe hier nur eine 6000er DSL Leitung, also kann ich im besten Fall mit etwa 700 kb/s laden.

Das ist nicht viel, und selbt ein einzelner Download kann dazu führen, das nebenher nichts anderes mehr funktioniert, oder YouTube die Videoqualität auf 144p drosselt. Ich habe den Deluge allerdings auf 230 kb/s gedrosselt, so das mir immer noch zwei Drittel der Leitung frei bleiben. Ich könnte jetzt auch noch beliebig viele weitere Torrents hinzufügen, Deluge erledigt die dann gleichzeitig. Man muß sich nicht darum kümmern, das läuft alles wie von selbst. Man kann die Geschwindigkeit auch zeitabhängig einstellen, so wie ich. Tagsüber, von morgens um 7 bis Nachts um 12 ist die Geschwindigkeit gedrosselt, so das ich immer problemlos surfen und Videos schauen kann, und von 0 Uhr bis 7 Uhr morgens darf dann Deluge die Leitung komplett ausnutzen.

Das kann man im Scheduler-Plugin auch noch für jeden Tag der Woche einzeln genau konfigurieren, und man kann auch einzelne Stunden komplett verbieten, dann ist das Feld rot. Das ist zum Beispiel sinnvoll, wenn man regelmäßig zeitgesteuerte Updates durchführen lässt. So kann man sicherstellen, das die immer mit der höchsten Geschwindigkeit laufen. Hat man mehrere Rechner, so wie ich, dann legt man die Updates am besten auf jedem Rechner auf einen anderen Wochentag, aber in die gleiche Stunde, und stellt dann die entsprechenden Stunden im Deluge auf rot. Sobald der Download abgeschloßen ist, steht im Fortschrittsbalken "Seeding". Das heißt das mein Rechner jetzt dabei mithilft, die Datei zu verteilen.

 Lädt jemand anders jetzt die gleiche Datei, so verbindet sich sein Rechner nicht nur mit dem Original-Server, sondern zusätzlich auch mit meinem Rechner. Er bekommt dann von mir ein paar Kilobyte pro Sekunde zusätzlich. Wenn es nur einen sogenannten Seed gibt, bringt das natürlich nicht viel, aber bei populären Dateien gibt es auch mal hunderte Seeds, so das man mit Torrent auch deutlich höhere Geschwindigkeiten erzielen kann. Diese Technik setzen zum Beipsiel die meisten Online-Spiel ein, um ihre regelmäßigen Updates zu verteilen. 
 
Nur das man dort nichts davon sieht, und den Vorgang auch kaum beeinflussen kann. Man braucht übrigens nicht immer Burnbit dazu. Viele Anbieter haben die Vorteile von Torrents inzwischen erkannt, und bieten gleich selbst entsprechende Downloads an.Dazu zählen etwa die Raspberry Foundation oder auch OpenSUSE. Ich möchte bei Gelegenheit auch noch das neueste SuSE Linux als Zweitsystem auf meinem Desktop installieren, dafür gibt es wie ihr seht direkt den Link auf BitTorrent.

Und hier sieht das Bild jetzt etwas anders aus: mein Rechner hat sich mit 94 anderen verbunden, und bekommt von jedem ein paar Kilobyte pro Sekunde. Die einzelnen Benutzer bemerken die wenigen kb gar nicht, aber ich kann die Datei trotzdem mit voller Geschwindigkeit laden. Bei der momentanen Geschwindigkeit wird das wohl über 5,5 Stunden dauern. Aber wie gesagt, das läuft auf dem Server, und ich muß meinen Rechner nicht die ganze Zeit laufen lassen.

DevelOS

Neben meiner Bastelei an PCs und meinem lokalen Netzwerk, beschäftige ich mich seit ein paar Jahren auch immer wieder mit der Programmierung von Microchip PIC Microcontrollern. Was ich daran besonders faszinierend finde ist die direkte verschmelzung von Code und Hardware, und das man damit quasi jedes Stückchen Elektronik irgendwie nutzen und ansprechen kann.
Inzwischen habe ich auch schon eine Menge kleinere Projekte umgesetzt, leider sind meine, teilweise sehr ausführlichen, Posts dazu verloren gegangen als blog.de abgeschaltet wurde.

Heute möchte ich etwas vorstellen was eigentlich eher ein Meta-Projekt ist. Wer sich mit PICs beschäftigt wird meistens recht schnell merken, das man bestimmte Funktionen immer wieder braucht, und dank der Programmierbarkeit in C kann man das meiste auch wiederverwenden. Aber dann muss man es immer wieder in ein neues Projekt kopieren, und mit neuen Funktionen zusammenbringen. Natürlich geht das, aber ich fand nach einiger Zeit ziemlich umständlich.

Daher habe ich irgendwann mal eine Art minimales Betriebssystem gebastelt, das beinahe beliebige Aufgaben erfüllen kann. Der Kern davon ist eine Pipeline, in die Nachrichten gesetzt werden können, die dann der Reihe nach abgearbeitet werden. Das passiert in einem einzigen langen switch()-Statement, das für jedes definierte Event ein Stückchen Code enthält.

Ein Beispiel:

Man verwendet einen AD-Kanal und möchte diesen periodisch auslesen. Am effektivsten geht das, indem man die Konvertierung startet, und dann auf den Interrupt wartet das der AD fertig ist. Dann bekommt man die Rohdaten zurück, die man dann umrechnen muß, um den tatsächlichen Wert zu erhalten. In meinem System sind das mehrere Events.

1. Das RTC-Modul meldet, das eine bestimmte Zeitspanne abgelaufen ist.
2. Dies löst ein Event aus um eine neue Konvertierung zu starten
3. Der AD konvertiert, die Rückgabe erfolgt per Interrupt
4. Im Interrupthandler wird nur ein neues Event erstellt, das die Rohdaten enthält
5. Die Rohdaten werden konvertiert, das Ergebnis wird wieder als Event in die Pipeline geschrieben
6. Je nach Funktion kann dieses Event wieder neue Events triggern, die Ausgabe auf ein Display z.B.

Das sieht auf den ersten Blick vielleicht etwas kompliziert aus, und mancher wird sich denken "Aber ein PIC hat doch gar keine RTC!". Nun, die RTC war eine der ersten Funktionen die ich auf diese Weise implementiert habe. Ein 16bit-Timer löst einen Interrupt aus, das wird als Event in die Pipeline geschrieben, und löst das hochzählen der RTC aus. Dort können wiederum andere Events ausgelöst werden. So kann man zum Beispiel angeben, das die Refresh-Routine für ein Display in einem bestimmten Intervall aufgerufen werden soll.

Das ist der Kern des DevelOS. Darum herum habe ich dann einige Module gebaut, z.B. das RTC-Modul, mehrere Module um Displays anzusprechen, ein Modul zur Verwaltung des internen EEProm und ähnliches. Um nicht jedes mal unnötig viel Speicher im PIC zu belegen, habe ich das ganze mit #define-Statements und #ifdef-Blöcken organisiert, so das man nur wenige Zeilen verändern muß um ganze Codeblöcke zu aktivieren, die über ettliche Dateien verteilt sein können.

Neben dieser rudimentären Modularisierung erreicht man auf diese Weise auch noch ein relativ gut funktionierendes Pseudo-Multitasking. Weil alles über die Pipeline läuft, können mehrere Aufgaben quasi nebeneinander laufen. Man muß nur aufpassen das man sie in möglichst kleine Stückchen zerlegt, so das der Chip mit einem einzelnen Event nicht zu lange hängen bleibt. In dem obigen Beispiel könnte man ja auch die Umrechnung des AD-Wertes direkt in der Interrupt-Routine unterbringen, aber das könnte eventuell die RTC aus dem Takt bringen.

Vielleicht erstelle ich dafür auch irgendwann ein Github-Projekt, mal sehen. Falls jemand Interesse an dem Code hat, darf mich gerne per Kommentar o.ä. kontaktieren, prinzipiell bin ich gerne bereit den Code zu teilen, unter der Bedingung, das darauf aufbauender Code wieder dem Gesamtprojekt zugute kommt.

Vinculum II

Es ist Zeit, mal den Aufbau meines Servers zu zeigen. Ich habe ihn vor ein paar Tagen mal wieder abgeschaltet und aufgemacht, vor allem um die Kabel etwas ordentlicher zu verlegen und ein XBee-Funkmodul anzuschließen. Dabei habe ich dann auch einige Fotos gemacht, so das ich jetzt hier ein bisschen was zeigen kann.

Hier sieht man das Herz des Servers, den Banana Pi. Links befinden sich die beiden USB-Ports und der Netzwerkanschluß, rechts sieht man die SD-Karte auf der sich das Betriebssystem befindet. Das war vorher eine 4 GB Karte, die eigentlich auch ausreicht. Nur habe ich inzwischen viele zusätzliche Funktionen eingebaut, es kommen auch immer wieder Updates, und so waren nur noch rund 800 MB frei. Das hätte noch lange ausgereicht. Jetzt gab es aber hier bei einem örtlichen Elektronikhändler eine 32 GB Karte für gerade mal 10 Euro im Angebot, und die war auch noch deutlich schneller als die ursprüngliche. Da habe ich natürlich sofort zugeschlagen und habe jetzt wieder reichlich Reserve.
Ganz vorne im Bild sieht man ein buntes Kabel, das ist eine der drei seriellen Schnittstellen des Banana, an die ich das XBee-Modul angeschloßen habe. Praktischerweise sind hier die beiden Datenleitungen, eine 3,3V und eine Masseleitung direkt nebeneinander, so das ich das Modul komplett mit diesem einen Kabel betreiben kann. Hinten sieht man noch das weiße µUSB-Kabel, das nur zur Stromversorgung dient, und daneben das rote SATA-Kabel. Darüber hinaus hat der Banana noch einen HDMI, einen Composite Videoausgang und einen Soundausgang, die ich aber nich verwende. Vielleicht werde ich irgendwann noch einen Lautsprecher einbauen für Fehler- und Statusmeldungen, aber das ist eine andere Geschichte.
Ganz rechts oberhalb der SD-Karte sieht man noch einen µUSB-Port, das ist auch nochmal ein vollwertiger USB2.0-Port den ich später nutzen könnte, wenn ich ihn denn brauche.

Und hier seht ihr den Server im Überblick. auf den ersten Blick wirkt das sehr chaotisch, vor allem wegen der Kabel. Links unten ist die ganze Stromverkabelung. Ich habe hier eine ATX-Buchse aus einem alten Netzwerk verwendet, und daran alle Kabel angelötet die ich so brauche. Einige Spannungen habe ich auf eine Schraubklemme geführt, das macht es etwas einfacher das System zu erweitern. Das grüne was man unten sieht, ist ein 8-Port Netzwerk Switch, und darüber sieht man einen der beiden USB2.0-Hubs. Dieser ist mit vier Festplatten bereits voll belegt, der zweite rechts unten steht für die nächsten Platten zur Verfügung. Es wäre vermutlich effizienter die Platten auf beide Hubs zu verteilen, aber ich bin mir nicht ganz sicher ob das nicht mein LVM-Setup durcheinander bringen würde. Doch dazu später mehr. Unten rechts sind auch zwei 3,5"-Festplatten montiert, jeweils 1 TB. Beide habe ich als USB-Festplatten gekauft und dann aus dem jeweiligen Gehäuse ausgebaut. Das war billiger als die Platten und USB-Adapter einzeln zu kaufen. Die Stromversorgung kommt dabei jeweil direkt aus dem ATX-Netzteil oben links. 

Und hier ein Blick in den oberen Laufwerkskäfig. Man sieht unten die 3,5" SATA-Platte mit 2TB, darüber sind zwei Montagerahmen eingebaut die jeweils vier 2,5"-Laufwerke aufnehmen können. Zwei Stück mit jeweils 1TB sind bereits vorhanden. In Einzelhandels-Byte sind somit 6TB verbaut, allerdings bleiben davon nach der Umrechnung nur noch etwa 950 Gigabyte bei den 1TB Platten und 1900 Gigabyte bei der 2TB Platte übrig, also zusammen ca. 5722 Gigabyte. Ein bisschen ist für das System selbst reserviert (gemountet als /var) und ein bisschen geht noch für das Dateisystem drauf, so das am Ende 5,35 "echte" TB als Netzlaufwerk zur Verfügung stehen.
Ich habe hier noch 6 Monatgeplätze für weitere Festplatten frei, und im Laufe der Zeit werde ich die auch sicher bestücken. Allerdings ist das immer eine Geldfrage, auf so eine Platte muß ich schon eine Weile sparen. Außerdem will ich auch den Netzwerk-Switch durch einen mit Gigabit-Ethernet ersetzen, damit ich den Banana wirklich mal ausreizen kann. Im Moment wird die Leistung eigentlich nur durch das 100MBit-Netzwerk begrenzt. Ich erreiche mit diesem System sowohl beim Lesen als auch beim Schreiben konstant 11-12 MB/s, also wirklich das Maximum was das Netzwerk hergeben kann. 

Hier rechts nochmal der Server im endgültigen Zustand mit der FritzBox oben drauf. Vom unteren USB-Hub habe ich ein Kabel nach außen gelegt, das ist aber im Moment nicht belegt. Ich möchte einfach die Möglichkeit haben eine externe Festplatte anzuschließen, falls mal ein Freund etwas größeres kopieren möchte. Das geht über WLAN nur sehr langsam, und extra Kabel legen ist mir zu nervig.
Das aufgerollte Netzwerkkabel links unten verbindet die FritzBox mit dem Switch, ich habe nur die überschüssige Länge im Gehäuse versteckt, damit es von außen etwas ordentlicher wirkt. Und wenn man genau hin schaut, sieht man oben rechts das kleine XBee-Funkmodul. Darüber werde ich irgendwann noch einen eigenen Post schreiben.

Hier noch die Front- und Rückansicht. Vorne habe ich zwei Lüfter angebracht, vor allem um die Festplatten zu kühlen. Die erreichen vor allem im Sommer schon recht bedenkliche Temperaturen. Hinten sieht man die beiden Netzwerkkabel rot ist der Server und weiß die Fritzbox. Und hier sieht man auch nochmal das Funkmodul, das ich einfach mit Panzertape am Gehäuse befestigt habe. Simpel aber effektiv. Man sieht auch das ich (fast) sämtliche Öffnungen des Gehäuses mit Paketband abgeklebt habe. Dadurch will ich einen kontrollierten Luftstrom sicherstellen. Die beiden Lüfter in der Front versorgen die Festplatten mit Frischluft, und das Netzteil hinten zieht die Luft wieder aus dem Gehäuse. Der Banana ist dabei so Montiert, das sein Kühlhörper direkt im Luftstrom des Netzteils liegt.

So, das wars vorerst mal. Aber es kommt sicher irgendwann noch mehr dazu.

Banana Pi vs. Raspberry Pi

In meinem letzten Post dazu habe ich ja schon geschrieben das ich zeitweise einen Raspberry Pi für meinen Homeserver benutzt habe. Und das ich jetzt einen Banana Pi verwende, der deutlich mehr Leistung hat. Aber warum das so ist, das habe ich nicht genau erklärt. Das will ich jetzt nachholen, weil es da oft ein Mißverständnis gibt.
Natürlich ist der Prozessor immer ein Faktor, und der Raspberry hat nur einen Singlecore mit maximal 1000 MHz. Von Hause aus läuft er sogar nur mit 700 MHz. Der Banana Pi dagegen hat einen Dualcore mit bis zu 1200 MHz. Das ist aber nur die halbe Wahrheit. Denn wenn es nur darum geht, Daten im Netzwerk herum zu kopieren, spielt die Prozessorleistung nur eine untergeordnete Rolle. Aber was ist dann der Grund, das der Raspberry nur gut 2 MB/s schafft, der Banana aber ganz locker 12 MB/s durch das 100 MBit Netzwerk schiebt?
Dazu muß man sich vor Augen halten, das beide Rechner auf einem sogenannten SoC beruhen. SoC steht für "System on a Chip", das bedeutet das hier ein ganzes System in einem einzelnen Chip steckt. Bei einem PC hat man einen Prozessor, und einen Chipsatz, oder auch Northbridge genannt. Diese Northbridge stellt alle Verbindungen innerhalb des Systems bereit, also heutzutage vor allem USB-Ports, SATA-Ports, PCI-Express-Anschlüsse, Netzwerkport, eben alles was man so braucht. Früher gab es auch noch eine sogenannte Southbridge, die den Arbeitsspeicher angesteuert hat. Diese Funktion ist aber inzwischen fast immer im Prozessor integriert.
Nun, bei einem SoC sind alle Komponenten in einem einzelnen Chip integriert. Nach aussen haben diese Chips meist einige spezielle Ports, wie z.B. HDMI, einige serielle Schnittstellen wie I2C und SPI, über die man andere Chips ansteuern kann, und insbesondere USB-Ports. Letztere sind für uns interessant, da wir hier unsere Festplatten und so weiter anschließen. Und auch der Netzwerk-Anschluß ist bei den beiden von mir betrachteten Systemen jeweils per USB angebunden. Wenn man weiß, das quasi alle Geräte bei einem Raspberry oder Banana per USB angesprochen werden, dann stellt sich unweigerlich die Frage, wieviele Ports hat denn das jeweilige SoC eigentlich, und wie sind die aufgeteilt?
Der Raspberry Pi basiert auf einem Broadcom BCM2835 SoC, das nach außen hin nur einen einzigen USB-Port hat. Dieser wird auf einen Chip geführt, der den Netzwerkanschluß und die externen USB-Ports bereit stellt. Wie man hier nachlesen kann, ist das bei allen Modellen des Raspberry bis heute genau gleich geblieben. Alle externen USB-Ports und das Netzwerk teilen sich also einen einzigen USB-Port.
Beim Banana Pi kommt dagegen ein Allwinner A20 SoC zum Einsatz, das nach außen über drei USB-Ports verfügt. Zusätzlich hat dieses SoC auch direkt einen Netzwerkanschluß und einen SATA-Port. Nachzulesen hier. Das heißt, beim Banana Pi sind alle USB-Ports eigenständig und bieten die volle Bandbreite, unabhängig von den anderen Anschlüssen.
Und genau das macht den großen Unterschied aus.

Vinculum

Wer mich persönlich kennt, der weiß das ich schon seit ca. 10 Jahren immer einen eigenen Homeserver betrieben habe.
Dafür kam im Lauf der Jahre immer wieder andere Hardware und Software zum Einsatz. Da ich meinen aktuellen Server in der nächsten Zeit mal wieder überarbeiten werde, will ich hier erstmal einen Überblick geben warum und wie ich den Server betreibe.

Zuerst mal das "Warum?". Natürlich eine berechtigte Frage. Für die Verwaltung des eigenen Heimnetzwerkes gibt es jede Menge verschiedene Router die ihren Job meistens recht zufriedenstellend erledigen. Will man Dateien für mehrere Geräte verfügbar machen, z.B. für den PC, das Smartphone und das Tablet, gibt es dafür wirklich gute und einfache NAS-Geräte, NAS steht für Network Attached Storage, zu deutsch grob "(ans) Netzwerk Angeschlossener Speicher". Also eigentlich könnte man auf einen Server ja verzichten. Ja, im Prinzip schon.

Aber aus mehreren Gründen will ich das nicht:

1. Kontrolle
Ich habe gerne die totale Kontrolle über alles, was in meinem Netzwerk passiert. Das ist mit einem herkömmlichen Router meist nur eingeschränkt möglich. Zum einen hat man auf einem dedizierten Server mehr Kontrolle über die Einstellungen, zum anderen hat man dort meistens viel ausführlichere Logfiles, so das man eventuelle Fehler leichter zurück verfolgen kann.

2. Spielraum
Ein Router in Kombination mit einem NAS gibt einem zwar auch die grundlegenden Funktionen eines Servers, aber man ist auf den Funktionsumfang festgelegt, den der jeweilige Hersteller vorgesehen hat. Auf einem Router kann man keine zusätzliche Software installieren, und ein NAS kann nur eine begrenzte Anzahl von Festplatten aufnehmen.

3. Effizienz
Für einen Router, ein NAS, eventuell noch einen Netzwerk-Switch oder eine externe USB-Festplatte braucht man jeweils ein eigenes Netzteil. Die haben dann jeweils eine Verlustleistung, und die addiert sich natürlich bei mehreren Geräten. In einem dedizierten Server hat man dagegen nur ein einziges Netzteil, so das Verluste nur an einer Stelle anfallen und bei geeigneter Wahl des Netzteils sehr gering ausfallen.

4. Ordnung
Wie schon erwähnt, für jedes einzelne Gerät braucht man ein eigenes Netzteil, und dann wollen ja alle Geräte untereinander auch noch eine Datenverbindung haben. Das ufert ganz schnell in einen regelrechten Kabelsalat aus. Und der ist nicht nur sehr unschön, sondern kann auch extrem nervig sein wenn man etwas ändern oder erweitern möchte.

Fazit: Ein Homeserver macht irgenwie doch Sinn.

Meine Server habe ich die meiste Zeit mit Linux als Betriebssystem betrieben. Namentlich SuSE Linux und Debian. SuSE lief auf meinen ersten Servern. Einer der ersten war ein Celeron 400 in einem Booksize-Gehäuse. Die Wahl fiel damals auf SuSE weil ich damit schon auf dem Desktop etwas Erfahrung hatte, und sich die damals aktuelle SuSE noch auf wenige 100 MB "eindampfen" ließ. Eine grafische Oberfläche brauchte ich nicht, das System sollte nur stabil und zuverlässig laufen. Damals hatte ich noch keine großen Festplatten, so hatte der Server nur etwa 20 GB Speicher. Davon wollte ich möglichst viel frei haben, um Daten auszutauschen. Und ein schlankes System bedeutet auch weniger Updates und weniger Fehlerquellen. Lange Zeit war ich damit wirklich zufrieden, allerdings hat das Mainboard nach einem Umzug nicht mehr funktioniert, und ein neuer Server musste her.
Da habe ich dann einen Minitower mit einem älteren Pentium Rechner bestückt. Die genauen Spezifikationen weiß ich inzwischen gar nicht mehr. Nachdem ich den lange Zeit wieder mit Linux betrieben habe, wollte ich irgendwann man Bitcoins minen, und das habe ich beim besten Willen nicht zum laufen bekommen. Und da auf meinen Rechnern sowieso die meiste Zeit Windows lief, habe ich dann mal einen Windows-Server betrieben. Dafür kam ein Windows Small Business Server 2003 zum Einsatz, für das ich die Lizenz schon einige Zeit herum liegen hatte. Was mir gut gefallen hat war die Verwaltung mehrerer Windows PC's in einer Domäne. Dabei kann man wirklich auf praktisch alle Funktionen und Einstellungen der angeschloßenen Rechner zugreifen, bis hin zu Einstellungen in der Registry. Und man kann auch viele Einstellungen für alle Rechner gemeinsam festlegen und Verwalten. Aber, die Einstellungen sind oft tief im System vergraben, und wenn man sich nicht wirklich auskennt, muß man viele Optionen sehr mühsam suchen. Und, damit man vernünftig mit dem System arbeiten kann, ist man auf die Remote-Desktop Steuerung angewiesen. Die funktioniert zwar wirklich gut, aber man braucht eben immer ein volles grafisches Windows System, um darauf zugreifen zu können. Ich habe meine SSH vermisst. Zudem hat der PC als Server wirklich viel Strom verbraucht, was mich irgendwann echt in Schwierigkeiten gebracht hat.

Und irgendwann habe ich dann den Raspberry Pi entdeckt. Ein Linux-Rechner in Scheckkartengröße, mit stromsparender ARM-Architektur. Zwar nicht besonders leistungsstark, aber für meine Zwecke fast perfekt. Zwar entstand daraus das übelste Kabelchaos aller Zeiten, aber das war für mich erträglich, weil ich alles zusammen in einer kleinen Abstellkammer unterbringen konnte, so das es quasi unsichtbar war. Der Rapberry mit eigenem Netzteil, eine USB-Festplatte mit eigenem Netzteil, ein Netzwerk-Switch mit eigenem Netzteil, eine Fritzbox mit eigenem Netzteil. Und ein paar Netzwerkkabel. Wirklich ziemliches Chaos, bei dem ich selbst zeitweise den Überblick verloren habe. Aber es hat gut funktioniert, obwohl die Datenraten immer relativ schlecht waren. Mehr als 2MB/s ging nicht beim Zugriff auf die USB-Platte über das Netzwerk. Das hatte mehrere Gründe, aber es war für mich soweit eigentlich genug. Ausreichend um Videos über das NJetzwerk zu schauen, was für mich bis heute eine der wichtigsten Funktionen des Servers darstellt. Damals noch mit einer modifizierten X-Box als MediaCenter. Und ein weiterer Einsatzzweck kam dazu, nämlich das abwickeln größerer Downloads. Ich habe eine relativ langsame Internetverbindung mit nur knapp 7 Mbit, und da dauert es schon eine kleine Ewigkeit wenn man ein größeres Linux-Image für den Raspberry laden will, oder gar ein DVD-Image für ein Desktop-Linux. Auch habe ich irgendwann angefangen eine Sammlung von Vorlesungen anzulegen, da sind wirklich viele auf archive.org verfügbar. Alle diese Sachen sind per Torrent verfügbar, da lag es nahe einen Torrent direkt auf dem Raspberry laufen zu lassen. Dadurch musste ich nichtmehr meinen großen Desktop PC dauernd laufen lassen, und große Downloads konnten über Nacht laufen wo sie mich nicht gestört haben.

Das führte dazu, das jemand anderes gerne auch eine solche "Seedbox" haben wollte, wie man einen Torrent-Server auch manchmal nennt. Allerdings hatte er keinen Raspberry, sondern einen Banana Pi, ein sehr ähnliches aber deutlich leistungsstärkeres System. Das Board für die Entwicklung eines passenden Images wurde mir großzügigerweise zur Verfügung gestellt, und verrichtet bis heute seinen Dienst in meinem aktuellen Server. Und irgendwann habe ich auch das Kabelchaos endgültig beseitigt. Dafür habe ich ein ATX-Netzteil verwendet, in einem normalen Minitower Gehäuse. Allerdings mit einem selbstgelöteten Kabelbaum, an einem ATX-Stecker aus einem alten Mainboard. Dadurch konnte ich nicht nur den Banana Pi, sondern auch die inzwischen 5 Festplatten, die Fritzbox und einen zusätzlichen Switch an einem einzigen Netzteil betreiben, das noch reichlich Reserve für weitere Festplatten oder sonstige Erweiterungen bietet. Und es ist alles zusammen in einem einzigen Gehäuse untergebracht, nimmt nur wenig Platz weg und kommt mit einer einzigen Steckdose aus. Die Geschwindigkeit ist für mein 100MBit-Netzwerk bei weitem ausreichend, ich erreiche sowohl beim Lesen als auch beim Schreiben rund 11-12 MB/s, also das Maximum was das Netzwerk hergibt. Der Banana selbst hat einen Gigabit Port, so das hier auch noch deutlich mehr möglich wäre. Da ich aber keinen Gigabit Switch besitze, kann er bisher gar nicht seine volle Leistung entfalten.

So weit, so gut. Und weiter?

Ich werde auch in Zukunft die Speicherkapazität Stück für Stück ausbauen. Inzwischen sind es mehr als 5 Terabyte. Irgendwann werde ich auch den Switch durch ein Gigabit Modell ersetzen, und die Fritzbox ist auch schon ziemlich in die Jahre gekommen. Sie bietet leider nur ein 54MBit WLAN, was mir inzwischen doch zu langsam ist. Außerdem möchte ich gerne die Spannungen des Netzteils genau überwachen können, dafür werde ich einen PIC Mikrocontroller verwenden, der mit dem Banana verbunden wird. Eventuell kommt auch noch ein Display dazu, das dann drahtlos per XBee mit dem Server verbunden wird. Aber da bin ich mir noch nicht ganz sicher. Auch eine Überwachung der Lastströme auf den einzelnen Spannungen wäre denkbar, oder die temperaturabhängige Regelung der Lüfter. Die Abstellkammer in der mein Server steht ist direkt unter dem Dach, und im Sommer wird es da sehr heiß. Teile des Systems haben da schon mal 60 Grad erreicht, was für Festplatten schon ungesund ist.

Sobald ich den Server wieder umbaue, werde ich natürlich hier ausführlich berichten. Dann auch wieder mit Bildern und Details.