EDV – Ende der Vernunft

Artikel-Schlagworte: „Benchmark“

Der Jörg regt sich hin und wieder über Benchmarks auf. Er prangert dabei zurecht an, das oftmals Äpfel mit Birnen verglichen werden. Aber selbst wenn einmal Äpfel mit Äpfel verglichen werden, sagen mir SPECints, TPC-C und SAPs nicht sonderlich viel. Ok, je höher je besser, trotzdem haben diese Buchstaben und Zahlen keinerlei Bezug zu meiner täglichen Arbeit.

In Zeiten von Dual-Quadcore sind viele Benchmarks sowieso überflüssig. Fast jeder Server bietet heutzutage mehr Rechen-Power als man je gebrauchen könnte, die Flaschenhälse liegen im wirklichen Leben ganz woanders z.B. bei den zwei 750GB S-ATA Platten – groß und langsam. Disk-IO Benchmarks lassen sich aber schlecht faken und sind zudem vollkommen unsexy.

Da ist es doch viel schöner, wenn man zwei Systeme unter echten Voraussetzungen vergleichen kann und feststellt, das Server A 6 Mails/Sekunde und Server B deren 20 erreicht. Tolles Ergebnis, nur kostet Server B mehr als das Dreifache von A. Das sind harte Fakten. Weiche Fakten sind dann eher Dinge wie der Stromverbrauch, wie viele konventionelle Systeme man ersetzen kann und wieviel Arbeit man durch die geringere Anzahl Server weniger hat.

Am Ende zählt man das zusammen und kommt zu einen Ergebnis dessen Rahmenbedingungen man selbst gewählt hat, man kann die Daten selbst deuten und kann auch kleinere Details erklären. Feine Sache so etwas.

Letztens in der Linux-User gelesen das codieren von MP3-Files würde bei einem 64Bit-System nur knapp halb so lange dauern. Ich habe daraufhin ein bischen getestet und das Ergebniss ist eindeutig. Von Ubuntu Feisty AMD64, Debian Etch AMD64 und Ubuntu Feisty 32Bit war letzteres das Schnellste im Codieren, gefolgt (mit 20% Abstand) von Feisty AMD64 und dann Etch AMD64.

Die Performance des eingesetzen Systems korreliert stark mit der Größe des Ego des Bedieners/Besitzers/Herstellers. Es können noch so viele Benchmarks dagegensprechen das eigene, handgepflegte System lässt sich mit natürlich nicht vergleichen, hierfür ist es einfach zu einmalig – in Fachkreisen spricht man dann von der gefühlten Geschwindigkeit.

Gute Nachricht zuerst: Man muss die NSLU nicht mehr “übertakten“, denn seit längeren wird sie mit der vollen Taktfrequenz von 266Mhz ausgeliefert. Bevor es los geht, ein paar Überlegungen hinsichtlich der anzuschließenden Storage.

Die NSLU verfügt über zwei USB-Anschlüsse. Zuerst spielte ich mit dem Gedanken sie durch einen USB-Hub zu erweitern. Am ersten Anschluss wollte ich einen USB-Stick anschließen und am zweiten den Hub mit den beiden USB-Festplatten. Klar, USB-Sticks haben eine begrenzte Lebendauer was Lese- und Schreibzyklen angeht, aber das Risiko wollte ich eingehen, der Stromverbrauch ist einfach zu verlockend. Bei geschickter Partitionierung (/home und Datengrab auf den Platten, der Rest auf dem Stick) kann man nachts die Platten in den Sleep-Modus laufen lassen und dann liegt die NSLU bei 10 Watt. Allerdings war dafür der Stick, warum auch immer, viel zu langsam. Also doch eine Platte an den ersten und eine mit den Hub an den zweiten, so kann auch der Drucker angeschlossen werden. Beim USB-Hub muss man, wie bei jeden anderen Hub (Netzwerk- oder Storage-Hub), daran denken das der Datentransfer blockiert für andere Dinge ist, wenn bereits ein anderes Gerät Daten überträgt. Also zwei Festplatten zugleich ist keine gute Idee.

Aber nun zur Installation. Es gibt fertige Installations-Images für Debian, einmal das offizielle und ein Inoffizielles. Beim Original Debian Image muss man mit einer USB-Netzwerkkarte arbeiten, da die interne Netzwerkkarte nur mit einen propitären Treiber Module zur Arbeit zu bewegen ist. Diesen Umstand umgeht man mit dem inoffziellen Image, welches das richtige Module enthält. Ich beziehe mich im weiteren auf das inoffielle Image.

Bevor man Debian installiert, sollte man die NSLU vorher einmal in Betrieb nehmen. Also mit einer IP-Adresse, Gateway, Netzwerkmaske und Eintrag für den DNS-Server versorgen, denn drauf greift die Installation später zurück. Hat man das Image heruntergeladen und entpackt, kann es einfach via Web-Interface hochgeladen (Administration/Upgrade) werden, jedoch sollte man vorher alle Platten/USB-Sticks abgestecken. Das Hochladen dauert einen Moment, generell sollte man etwas Geduld mitbringen, denn alles dauert ein bischen länger als sonst. Wenn das Gerät dreimal gepiept hat ist es soweit, man kann es wieder aus machen und die Festplatte-/Sticks wie gewünscht anstöpseln und anschließend wieder einschalten.

Nun kann man sich via ssh installer@IP-Adresse (Passwort: install) einloggen und stößt dann auf einen normalen Debian-Installer den ich nicht weiter vorstellen möchte. Er kümmert sich um die Partitionierung, Installation der Software und dem bootfähig machen des Systems. Ist man soweit durch steht vor einen ein normales Debian-System.

Meine erste Installation dauerte ewig und lief mehrfach in einen ssh timeout. Sie war mit USB-Stick und Festplatten via Hub am ersten Anschluss aufgebaut und ich testete mit

dd if=/dev/zero of=test.dat bs=1M count=100

die Geschwindigkeit. Das ist sicher kein echter Benchmark, aber die Ergebnisse lassen sich schnell ermitteln und gut vergleichen, auch wenn sie anfangs sehr erschütternd waren. Gerade einmal 1.4MB/s standen auf den Tacho, sowohl beim Stick als auch bei der Platte. Ich richtete dann das mounten via UUID ein, um die Platte frei umherstecken zu können und siehe da: die Platte lag, wenn sie alleine angeschlossen war, bei 13.5MB/s. Der USB-Stick war also zu langsam, obwohl er mit USB2 arbeitete. Komischerweise liefert er bei meinen Desktop-PC die volle Leistung. Keine Ahnung warum.

Also neu installiert und die Firmware mit Upslug2 via Netzwerk eingespielt. Tolle Sache, denn so kann man im Prinzip die NSLU nicht zerflashen. Die Installation ging durch die am ersten Anschluss hängende Festplatte recht fix und auch das fertige System lag dann wieder bei 13.5MB/s Datentransfer im System.

Zeit sich mit der Netzwerkgeschwindigleit zu befassen. Beim normalen NFS-Mount lag sie bei 4.6MB/s, per FTP bei etwa 5.2MB/s. Der begrenzende Faktor war bei allen Messungen (welch Überraschung) die CPU. Mal NFSv4 probiert, welches von der Performance besser sein soll. Nunja, es lag mal etwas unter, mal etwas über NFSv3, insgesamt nichts nennenswertes. Spasseshalber hatte ich mein /home vom jetzigen Server (der etwa 8MB/s macht) auf die NSLU verlegt und es war ein ganz normales Arbeiten für mich möglich – Test also bestanden.

Was noch aussteht ist die Übernahme der Funktion des jetzigen Servers. Also NFS, SMB/CIFS, IMAP und SMTP. Ich bin mal gespannt wie ich mit den 32MB RAM hinkomme.