/dev/blog/ID10T

Advertisement

Raspberry Pi: SD-Karten Tests

• Hardware and Linux • Comments

Update 17.08.2011:
Für Leute, die es eilig haben hier die beiden besten Karten: Transcend SDHC 16GB Class 6* und SanDisk Class 10 Ultra SDHC 8GB*.

Um eine gute Karte für meinen Raspberry Pi zu finden, habe ich mir bisher schon etwas Mühe gemacht. Denn nur weil Class 10 auf der Karte drauf steht, heißt das noch lange nicht, dass sie für die Zugriffe, die ein Betriebssystem braucht, optimiert ist. Wen das genauer interessiert, dem empfehle ich die Studie dieses Threads im Raspberry Pi Forums oder dieses Threads im XDA-Developers Forum.
Also habe ich mir zum Testen ein eigenes kleines Skript geschrieben, welches auf dem Raspberry Pi ausgeführt wird und sowohl die Schreibgeschwindigkeit von /dev/null als auch von /dev/random misst. Die Ergebnisse sind untereinander vergleichbar, nicht jedoch mit anderen Tests. Alle Tests wurden mit dem "alten" Debian Wheezy Image ausgeführt, welches noch nicht so gut optimiert ist.
Das Skript sieht so aus:

#!/bin/bash
#
# SD Performance Skript for
# Raspberry Pi
# Made by m3adow
#

sync
mkdir sdperf
echo -e "\n=== Testing /dev/zero Performance ==="
TZ="$(date +%s%N)"
time ( for item in `seq 1 1000`; do dd if=/dev/zero of=sdperf/zerotest.$item bs=16k count=10 >& /dev/null; done;)
TZ="$(($(date +%s%N) -TZ))"

rm -rf sdperf/
mkdir sdperf/

echo -e "\n=== Testing /dev/urandom Performance ==="
TR="$(date +%s%N)"
time (for item in `seq 1 1000`; do dd if=/dev/urandom of=sdperf/randtest.$item bs=16k count=10 >& /dev/null; done)
TR="$(($(date +%s%N) -TR))"
TRS="$((TR/1000000000))"

rm -rf sdperf/

echo -e "\n $TZ ns"
echo -e "\n==== Summary ====\n"
echo -e "\n Sequential Write (MB/s): \c"
echo -n $TZ  |awk '{OFMT="%.2f";print 160000000000/$0}'
echo -e "\n Random Write (MB/s): \c"
echo -n $TR  |awk '{OFMT="%.2f";print 160000000000/$0}'
sync

Im Endeffekt macht es nichts anderes, als 1000 Mal 10 Blöcke mit jeweils 16k Blocksize in ein Verzeichnis zu schreiben, die Zeit zu stoppen und die Geschwindigkeit auszurechnen. Nach den Tests löscht es die entsprechenden Dateien (bzw. den Ordner) wieder.

Da es sicherlich mehr Leute gibt, die eine schnelle SD-Karte für ihren Raspberry Pi haben wollen, werde ich hier meine Ergebnisse posten, bis ich eine Karte finde, die mir zusagt. Ich mache jeweils drei Durchgänge, um eventuelle Ausreißer zu erkennen. Ich gebe jeweils die Geschwindigkeiten der /dev/zero Schreibdurchgänge und darunter die Geschwindigkeiten der drei /dev/urandom Schreibdurchgänge an.
Hinweis: Ich hatte vor Beginn meiner Tests noch eine Samsung MB-SPAGA/EU Class 10 16GB* bestellt, doch diese war mir zu langsam.

Platinum 16 GB Class 6 SDHC*

/dev/zero (1./2./3. Run) [MB/s]: 0.97/1.37/1.09
/dev/urandom (1./2./3. Run) [MB/s]: 0.5/0.51/0.48
Fazit: Zu langsam
Transcend SDHC 8GB Class 4*
/dev/zero (1./2./3. Run) [MB/s]: 1.08/1.16/1.35
/dev/urandom (1./2./3. Run) [MB/s]: 0.51/0.52/0.51
Fazit: Zu langsam
SanDisk Extreme III 2GB Class 6
/dev/zero (1./2./3. Run) [MB/s]: 4.78/4.58/4.64
/dev/urandom (1./2./3. Run) [MB/s]: 0.78/0.79/0.78
Fazit: Meine alte Karte, gute Geschwindigkeit

Update 06.08.2012:

SanDisk Ultra SDHC 8GB Class 4*

/dev/zero (1./2./3. Run) [MB/s]: 1.44/1.50/1.7
/dev/urandom (1./2./3. Run) [MB/s]: 0.57/0.57/0.6
Anmerkung: Ich habe diese Karte bestellt, aber eine SanDisk Ultra 8GB Class 6 Karte bekommen. Diese habe ich getestet.
Fazit: Zu langsam
SanDisk Ultra SDHC 16GB Class 4*
/dev/zero (1./2./3. Run) [MB/s]: 3.56/3.47/3.57
/dev/urandom (1./2./3. Run) [MB/s]: 0.73/0.73/0.74
Anmerkung: Ich habe diese Karte bestellt, aber eine SanDisk Ultra 16GB Class 10 Karte bekommen. Diese habe ich getestet.
Fazit: Zu langsam

Update 17.08.2012:

Kingston Class 10 SDHC 8GB*
/dev/zero (1./2./3. Run) [MB/s]: 1.80/1.68/1.62
/dev/urandom (1./2./3. Run) [MB/s]: 0.57/0.60/0.56
Fazit: Zu langsam
Kingston SDHC Class 4 16 GB*
/dev/zero (1./2./3. Run) [MB/s]: 0.75/1.02/1.07
/dev/urandom (1./2./3. Run) [MB/s]: 0.43/0.41/0.38
Fazit: Zu langsam
SanDisk Class 10 Ultra SDHC 8GB*
/dev/zero (1./2./3. Run) [MB/s]: 3.29/3.42/3.25
/dev/urandom (1./2./3. Run) [MB/s]: 0.75/0.73/0.73
Fazit: Gute Geschwindigkeit, beste 8GB-Karte
Lexar 8GB Class 6*
/dev/zero (1./2./3. Run) [MB/s]: 1.06/0.99/1.07
/dev/urandom (1./2./3. Run) [MB/s]: 0.47/0.49/0.45
Fazit: Zu langsam
Lexar SDHC 4GB Class 6*
/dev/zero (1./2./3. Run) [MB/s]: 1.33/1.77/1.38
/dev/urandom (1./2./3. Run) [MB/s]: 0.52/0.54/0.53
Fazit: Zu langsam
Transcend SDHC 16GB Class 6*
/dev/zero (1./2./3. Run) [MB/s]: 3.93/3.43/3.25
/dev/urandom (1./2./3. Run) [MB/s]: 0.75/0.73/0.73
Fazit: Gute Geschwindigkeit, beste 16GB-Karte

Transcend SDHC 8GB Class 6*
/dev/zero (1./2./3. Run) [MB/s]: 1.68/2.13/1.61
/dev/urandom (1./2./3. Run) [MB/s]: 0.59/0.55/0.57
Fazit: Zu langsam

Falls Ihr Erfahrungen mit SD-Karten gemacht habt, teilt sie hier gerne, ich habe mir die Transcend 16 GB behalten.

*=Affiliatelink

Linux: Geschwindigkeit von Wechseldatenträgern testen

• Linux • Comments

Eine schnelle Notiz für zwischendurch:

Wenn ihr mal auf der Commandline die Lese- und/oder Schreibgeschwindigkeit von SD-Karten, USB-Sticks oder Festplatten messen wollt, gibt es da eine einfache Möglichkeit für.
Für Lesegeschwindigkeit:

hdparm -tT /dev/sda

Die Ausgabe sieht dann irgendwie so aus:

 Timing cached reads:   290 MB in  2.01 seconds = 144.21 MB/sec
 Timing buffered disk reads:  60 MB in  3.04 seconds =  19.72 MB/sec

Für Schreibgeschwindigkeit nutzen wir dann einen simplen dd-Befehl:

dd count=100 bs=1M if=/dev/urandom of=/media/usb/test

Nach einiger Zeit sollte die Ausgabe dann erscheinen und etwa so aussehen:

100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 115.832 s, 905 kB/s

Wie ihr seht, sollte ich diesen lahmen USB-Stick nicht als temporäre Festplatte nutzen.

OT: Brillenanalyse

• Offtopic • Comments

Dieses Bild habe ich eben bei Gilly entdeckt. Da ich auch Brillenträger bin und es lustig fand, verbreite ich es weiter.

Nach Studie meiner Brille bin ich offensichtlich sehr gelehrt.

Sieht doch am ehesten nach einem "Scholar" aus oder? ;-)

 

ESXi: Ein paar Hilfsskripte und Komfortfunktionen

• Administration • Comments

Der VMware ESXi ist in vielen Punkten deutlich abgespeckt. Dementsprechend fehlen auch viele Komfortfunktionen, die einem das Arbeiten auf der Kommandozeile erleichtern würden. Ich werde hier ein paar meiner Lösungen vorstellen. Dabei beziehe ich mich einzig auf den root-Benutzer, da der in der Regel die Arbeiten auf der Shell erledigt. Dazu eine kurze Erklärung der beiden am Meisten benutzten Dateien: Die Datei /etc/profiles ist die Datei, die bei jedem Login per SSH ausgeführt wird. Sie ist mit der deutlich bekannteren bash.rc vergleichbar. Die Datei /etc/rc.local wird bei jedem Systemstart einmalig ausgeführt und ist in der Funktionsweise mit der in vielen Linux Distributionen vorhandenen gleichnamigen Datei weitestgehend identisch. Diese beiden Dateien nutze ich hauptsächlich, um mir den Arbeitsalltag zu erleichtern.

Shell Funktionen

Die ersten Anpassungen, die ich auf jedem Linux-System vornehme, sind eigene Aliases und Anpassungen der Standardbefehle. Beim ESXi werden diese Aliases in die Datei /etc/profiles geschrieben, wie ich schonmal beschrieben habe. Meine Anpassungen hier sind zwar banal, mir aber sehr wichtig.

alias ls='ls -A'
alias la='ls -lA'
alias ll='ls -l'
alias l='ls -A'
alias ..='cd ..'
alias ...='cd ../..'

Dann noch ein

source /etc/profiles

und die Aliases funktionieren.

Pfad für Usercsripts

Außerdem brauche ich auch einige Zusatzbefehle in Form von eigenen Skripten auf der Shell und auch im System. Allerdings lassen sich Userscripts nicht einfach in einem der Verzeichnisse der PATH-Variable - also /bin oder /sbin - ablegen, diese Verzeichnisse werden bei jedem Neustart vom ESXi zurückgesetzt. Auch gibt es kein Verzeichnis wie /usr/local/sbin, wie man es von diversen Linux Distributionen gewohnt ist. Deswegen lege ich meine Userscripts immer innerhalb des Datastores ab, etwa im Ordner /vmfs/volumes/datastore/administration/sbin. Um diese aber trotzdem ohne Pfadangabe ausführen zu können, gibt es zwei Stellen, an denen ihr den Pfad oder die Pfade zu euren eigenen Skripten angeben beziehungsweise ergänzen solltet.
Zuerst ist eine Anpassung der PATH-Variable in der /etc/profiles nötig. Dazu einfach die gewünschten Pfade vor dem export PATH-Befehl zur PATH-Variable hinzufügen.

PATH=$PATH:/vmfs/volumes/datastore/administration/sbin
export PATH

Nach einem

source /etc/profiles

sind die Scripts in der Shell verfügbar.
Wenn ihr sie allerdings in Cronjobs benutzen wollt, müsst ihr entweder den kompletten Pfad angeben oder die zweite Anpassung vornehmen. Diese muss in der Datei /etc/rc.local geschehen. In der zweiten Zeile solltet ihr dort eure benötigten Pfade ergänzen.

export PATH=/sbin:/bin:/vmfs/volumes/datastore/administration/sbin

Anschließend

source /etc/rc.local

und auch euer System kennt diese Pfade.

Symbolische Links und Cronjobs

Um mir die Navigation etwas zu erleichtern, lasse ich mir auch noch bei jedem Systemstart einige Symlinks erstellen. Diese kommen in die /etc/rc.local. Zusätzlich noch einen backup-Ordner, in dem die Backups abgelegt und weiterverarbeitet werden.

ln -s /vmfs/volumes/datastore/ /datastore
ln -s /vmfs/volumes/datastore/administration/sbin/ /userscripts
ln -s /vmfs/datastore/BACKUP /BACKUP
mkdir /backup

Zusätzlich werden in der /etc/rc.local auch noch sämtliche Cronjobs neu geschrieben, da auch die Datei /var/spool/cron/crontabs/root, in der die Cronjobs liegen, bei jedem Start wieder in ihren Ursprungszustand zurückversetzt wird.

/bin/kill $(cat /var/run/crond.pid)
/bin/echo "00 12 * * 6 /vmfs/volumes/datastore/administration/vm-backup.sh > /var/log/backup.log" >> /var/spool/cron/crontabs/root
/bin/busybox crond

Erst beende ich die aktuelle Cronjob-Instanz, dann werden alle Cronjobs per echo-Befehl an die Datei angehängt. Anschließend wird der Cron Daemon neu gestartet.

Nützliche Skripte

Abschließend will ich noch zwei Skripte vorstellen, die vom Funktionsablauf identisch sind, mir aber immer wieder helfen. Die Skripte starten den Cron Daemon beziehungsweise den Inet Daemon neu. Ich lasse sie unkommentiert und jeder kann selbst entscheiden, ob sie nützlich sind oder nicht. Mir haben sie grade bei der Einrichtung von Backup und Rsync geholfen.
Für den Crond sieht das so aus:

#!/bin/ash
echo "Alte PID fuer Cron:"
cat /var/run/crond.pid
echo "starte neu..."
kill $(cat /var/run/crond.pid)
sleep 1
crond
sleep 1
echo "Neue PID fuer Cron:"
cat /var/run/crond.pid

Und für den Inetd ändert es sich nur geringfügig:

#!/bin/ash
echo "Alte PID fuer Inetd:"
cat /var/run/inetd.pid
echo "starte neu..."
kill $(cat /var/run/inetd.pid)
sleep 1
inetd
sleep 1
echo "Neue PID fuer inetd:"
cat /var/run/inetd.pid

Nach diesem Hinzufügen von Aliases, Symlinks, Ordnern, Cronjobs und Userscripts ist der ESXi für mich direkt viel bedienbarer.

Raspberry Pi: Erste Eindrücke

• Hardware • Comments

Mein Raspberry Pi ist da. Wem der Name nichts sagt, der kann sich auf der Homepage der Raspberry Pi Foundation einlesen. Kurz beschrieben: Der Pi ist ein Minicomputer nicht viel größer als eine Kreditkarte. Er wird von einem ARM-Prozessor angetrieben und kostet lediglich 35$. Er ist zwar nicht der schnellste, aber sehr sparsam. Darum perfekt geeignet für kleine Serveraufgaben.

Ich plane, den Raspberry Pi als DHCP-Server und DNS-Cache bei uns im Heimnetzwerk einzusetzen. Außerdem will ich noch die Geschwindigkeit und Funktionalität der Groupware Zarafa darauf testen. Im April habe ich ein Exemplar bestellt, am Freitag kam es an.

Schön klein ist er schonmal, grade mal so groß wie mein HTC Desire. Da ich noch nicht die perfekte Peripherie habe, mein Netzteil ist nicht so leistungsstark, wie es empfohlen wird und die SD-Karte nicht so schnell wie meine bestellte, kann ich über die Performance noch nicht so viel sagen.

Allerdings kann ich schonmal eine kleine Fehlerbehebung teilen:

Die temporär von mir genutzte SD-Karte ist eine 2GB Sandisk Extreme III. Mit den auf der offiziellen Downloadseite bereitgestellten Linuximages kam bei mir immer eine Kernel Panic-Meldung beim Start. Auch die Images der von mir ins Auge gefassten Raspbian Distribution brachten keine Abhilfe. Erst mit der Beta von Debian Wheezy war mir ein Systemstart möglich.

Mit dem momentanen Systemsetup wird das Gerät kaum handwarm, das dürfte sich aber mit entsprechender Stromzufuhr und Last noch ändern. Durch fehlende bewegliche Teile ist der Pi natürlich auch komplett ruhig.

In den nächsten Tagen, Wochen und Monaten werde ich hier weitere Eindrücke und eventuell die ein oder andere Anleitung mit euch teilen. Allerdings bin ich bekanntlich mit weniger logischen Dingen als PCs schon sehr gut ausgelastet, es kann also durchaus etwas dauern. :-P

Aber hier schonmal eine kleine Agenda, was ich plane zu machen und eventuell auch zu berichten:

Wie gesagt kann sich das aber durchaus noch ändern und es wird auf jeden Fall dauern.

Advertisement