SSD? Pah, langsam :-)

[Christian Brandt]

Gerade habe ich unter Ubuntu 12.04 Beta 1 ein RAID5 aus acht Daten- und
einer Parity Platte je 1TB - schon ein paar Jahre alt - getestet.

hdparm -t /dev/md1 liefert schnuckelige 650MB/s.

Die average Seek-Time über die ganze Platte ist natürlich nicht so
dolle. ABER ein Seek-Test in einer 500MB grossen Datenbank sah mit
"average seek time" von 0,08ms ist doch recht anständig. Und ja, das ist
kein Tippfehler. Ich denke das kommt daher daß acht Platten mit 50-60MB
pro Track ohnehin kaum seeken müssen und natürlich acht Platten auch
32*8=256MB Cache haben, sozusagen Shortstroking durch Spezialisierung
auf eine Anwendung.

Jedenfalls muß man bei diesem Rechner erstmal keine SSD zur
Leistungssteigerung einbauen :-)

Christian Brandt

[Christian Potzinger]

Christian Brandt schrieb:

> Jedenfalls muß man bei diesem Rechner erstmal
> keine SSD zur Leistungssteigerung einbauen :-)

Angeber ;-P

Aber wie wäre es mit einem RAID5 mit 8 SSD Platten? :-]
--
ryl: G'Kar

[Cornelia Schneider]

Christian Potzinger <news-...@gmx.at> wrote in
news:XnsA01EB52...@ID-303851.user.individual.de:

> Aber wie wäre es mit einem RAID5 mit 8 SSD Platten? :-]

Vor allem teuer :-)

Cornelia

--
Be out and be proud - today is the first day of the rest of your life
Support Transgenre Strasbourg : www.sts67.org
GPG key ID 83FF7452

[Marcel Müller]

On 22.03.2012 11:16, Christian Brandt wrote:
> Gerade habe ich unter Ubuntu 12.04 Beta 1 ein RAID5 aus acht Daten- und
> einer Parity Platte je 1TB - schon ein paar Jahre alt - getestet.
>
> hdparm -t /dev/md1 liefert schnuckelige 650MB/s.

Sieht toll aus, aber im praktischen Betrieb ist dieser Parameter
vollständig irrelevant. (Es gibt ganz wenige Ausnahmen.)

Wir haben bei uns mal eine Statistik gefahren. Die mittlere I/O-Block
Größe über alle Zugriffe liegt bei knapp 20kB. Vermessungsgrundlage
waren alle IOs von von ca. 3 Dutzend Servern über einen Zeitraum von
einem Tag. Auf anderen LUNs mit anderen Servern und auch virtualisierten
Clients sah es aber auch nicht signifikant anders aus.

Um 20kB zu lesen braucht dein System rechnerisch ca. 30µs. In der Praxis
wird es natürlich mehr sein, weil es unter der Stripe-Size liegt.
Mutmaßlich um die 200µs. Aber im Durchsatz bleibt es dabei.
Eine Zugriffszeit dürfte bei TB-Platten im Mittel um die 14-15ms liegen
(max. 70 IOPS). Heißt, auf 200µs I/O kommt bei jeder Platte etwa
14-15ms. Kurzum, die Zugriffszeit ist "nur" gut 70 mal weniger relevant,
wie der Durchsatz. Wäre die Stripe-Size kleiner als die 20kB, wäre das
Verhältnis sogar noch extremer, weil nun für einen Zugriff immer mehrere
Platten warten müssten und in der Zeit nicht mehr für Datentransfers zur
Verfügung stünden. Also Stripesize bei Desktopplatten immer schön groß
machen.

> Die average Seek-Time über die ganze Platte ist natürlich nicht so
> dolle. ABER ein Seek-Test in einer 500MB grossen Datenbank sah mit
> "average seek time" von 0,08ms ist doch recht anständig. Und ja, das ist
> kein Tippfehler.

Ein Tippfehler vielleicht nicht, aber Messfehler aber sicherlich. Hier
hat Dich sicher ein Cache ins Bockshorn gejagt. Selbst, wenn man nur ein
sechzentel der Plattenkapazität nutzt und damit häufig von
Track-To-Track Seeks profitiert - eine gängige Methode, um Platten in
Servern in den Hintern zu treten -, ist ein Beschleunigungsfaktor von
ca. 180 damit sicher nicht zu erklären.
Dass Caches die Sache beschleunigen, ist außer Frage und das sollte man
auch immer nutzen. Nur tun sie das auch ohne RAID und insofern sollte
man diesen Nutzen nicht dm RAID zuschreiben.

(By the way, war das wirklich average seek, oder nicht doch eher und
vernünftiger average access time?)

> Ich denke das kommt daher daß acht Platten mit 50-60MB
> pro Track ohnehin kaum seeken müssen und natürlich acht Platten auch
> 32*8=256MB Cache haben, sozusagen Shortstroking durch Spezialisierung
> auf eine Anwendung.

Exakt. Wenn Du gescheitere Werte haben willst, brauchst Du die
differenzielle Entwicklung bei unterschiedlichen Größen betrachten. Die
mittlere Zugriffszeit auf jeder /zusätzlichen/ 100 GB dürfte erheblich
schlechter ausfallen.

> Jedenfalls muß man bei diesem Rechner erstmal keine SSD zur
> Leistungssteigerung einbauen :-)

Das /muss/ man bei keinem Rechner. Die Geschwindigkeit wird aber auf
besseres Desktop-Niveau einbrechen, sobald das RAID erst mal voll ist
und auch in seiner Kapazität genutzt wird. Lediglich bei vielen
parallelen zugriffen werden (effektiv) 8 Spindeln immer schneller sein
als eine. Das bringt z.B. beim Booten einiges. Wenn man jedoch nicht
untypisch für einen Desktop auf eine einzige Anwendung wartet, ist der
Effekt üblicherweise eher gering, da die meisten Anwendungen kaum
parallele I/O-Anfragen absetzen.
Eine zusätzliche SSD, wäre aber sicher billiger und nebenbei auch
deutlichst Energiesparender gewesen, wenn es primär darum geht, einen
Rechner zu beschleunigen. Wenn es Primär darum geht 8TB zu haben, ist
das natürlich nicht so. Dann ist der Vergleich mit einer SSD aber auch
irgendwie unangebracht.


Marcel

[Marcel Müller]

On 23.03.2012 01:20, Cornelia Schneider wrote:
> Christian Potzinger<news-...@gmx.at> wrote in
> news:XnsA01EB52...@ID-303851.user.individual.de:
>
>> Aber wie wäre es mit einem RAID5 mit 8 SSD Platten? :-]
>
> Vor allem teuer :-)

Und aus Geschwindigkeitssicht auch nicht sinnvoll. Das RAID-Subsystem
wird gegenüber den geringen Latenzen der SSDs in seinem Overhead nicht
mehr vernachlässigbar sein und daher den Durchsatz in IOPS eher spürbar
reduzieren.


Marcel

[Christian Brandt]

Am 23.03.2012 01:20, schrieb Cornelia Schneider:

>> Aber wie wäre es mit einem RAID5 mit 8 SSD Platten? :-]
> Vor allem teuer :-)

Vor allen Dingen bringts weniger als erwartet:

Ein Bekannter hat vier 256GB SSDs dahingehend im Einsatz. Die
Onboard-Schnittstellen von Z68-Boards ist bei etwa 800MB paralleler Last
am Ende. D.h. wollte er wirklich die theoretischen 1800MB/s nutzen müßte
er zwei Platten an den beiden Onboard-SATA6-Anschlüssen betreiben und
zwei an einem zusätzlichem SATA-Controller. Womit sich diese vier
Laufwerke unter Windows nicht als RAID0 betreiben lassen (ev mit
Windowsboardmitteln als dynamischer Datenträger RAID0 aber das Ding ist
ja deprecated und eher zäh und man muß saudumm herumpartitionieren).

Die meisten SATA-Controller sind intern simpel aufgebaut: Beide
SATA-Ports werden direkt auf eine PCIE-Leitung gelegt - ergo bekommen
beide zusammen am Z68 auch nur 250MB/s.

Der kürzlich hier genannte Digitux 30dingsirgendwas hat vier Anschlüsse
die einzeln auf je eine PCIEx1 auf einem PCIEx4 gelegt werden. Das läuft
immerhin mit 250MB/s PRO Laufwerk und nicht mehr für alle zusammen. Oder
man steckt den Controller in den zweiten SLI-Slot, dann ist die
Grafikkarte nur noch x8 angebunden.

Achja, daß restlos alle preiswerten Controller auf dem
Marvell-SATA6-Chip beruhen kommt dazu: Das Ding ist broken by Design und
defakto für SATA6G nicht nutzbar.

Alternativ könnte er einen RAID-Controller verwenden. Aber es gibt
keinen RAID-Controller der schnell genug ist und in einen
PCIEx4-Anschluß paßt. Ergo kappt ihm das die halbe Grafikkartenanbindung.

Oder er nimmt einen X79 oder wie die neue 2011er Plattform heißt. Die
hat dann aber pro Core weniger Leistung und Board mit CPU kostet fast
das Doppelte eines Z68 mit i7-2600k.

Oder man gibts auf und stöpselt alle vier SSDs an onboard-Komponenten
und ist glücklich daß man wenigstens 40% der theoretischen Leistung
bekommt :-)

Sein System stand übrigens neben einem sehr ähnlichem Z68 mit 1x2TB
Platte und 1x60GB SSD-Cache. Beim normalem Alltags- und Spielegeschäft
sieht man NULL Unterschied oder bestenfalls in der Art "Vom Booten bis
zum Gameplay von BF3 braucht das 4xSSD-System 48 Sekunden, das
Cache-SSD-System 51 Sekunden, ohne Caching-SSD 90 Sekunden".

Christian Brandt

[Joseph Terner]

On Fri, 23 Mar 2012 08:39:58 +0100, Christian Brandt wrote:
> Am 23.03.2012 01:20, schrieb Cornelia Schneider:
>
>>> Aber wie wäre es mit einem RAID5 mit 8 SSD Platten? :-]
>> Vor allem teuer :-)
>
> Vor allen Dingen bringts weniger als erwartet:
>
> Ein Bekannter hat vier 256GB SSDs dahingehend im Einsatz. Die
> Onboard-Schnittstellen von Z68-Boards ist bei etwa 800MB paralleler Last
> am Ende.

Mit Windows? Das ist nun ja auch nicht gerade ein Betriebssystem für
Supercomputing. ;-)

> Die meisten SATA-Controller sind intern simpel aufgebaut: Beide
> SATA-Ports werden direkt auf eine PCIE-Leitung gelegt - ergo bekommen
> beide zusammen am Z68 auch nur 250MB/s.

Wir sind inzwischen bei PCIe 2.0 (500 MB/s pro Lane) und mit Ivy Bridge
bei 3.0.

> Achja, daß restlos alle preiswerten Controller auf dem
> Marvell-SATA6-Chip beruhen kommt dazu: Das Ding ist broken by Design und
> defakto für SATA6G nicht nutzbar.

-v

> Alternativ könnte er einen RAID-Controller verwenden. Aber es gibt
> keinen RAID-Controller der schnell genug ist und in einen
> PCIEx4-Anschluß paßt. Ergo kappt ihm das die halbe Grafikkartenanbindung.

PCIe-x4-Slots sind bei Consumermainboards eh nicht verbreitet, eher findet
max x16-Slots mit vier Lanes. Dort paßt jeder Controller hinein und läuft
dann eben mit vier Lanes (2 GB/s).

ciao, Joseph

[Gerhard Hoffmann]

On 03/22/2012 11:16 AM, Christian Brandt wrote:
> Gerade habe ich unter Ubuntu 12.04 Beta 1 ein RAID5 aus acht Daten- und
> einer Parity Platte je 1TB - schon ein paar Jahre alt - getestet.
>
> hdparm -t /dev/md1 liefert schnuckelige 650MB/s.

Ich hatte einige Jahre in einem CoreDuo einen Areca-Controller mit 4
ge-stripe-ten WD Raptors, zuerst die 70GB-Version und dann die 150GB.
Das gab auch etwa 500 MB/sec, sehr befriedigend, aber laut.



Dies schreibe ich jetzt auf einem Dell Precision 6600 Laptop, der kann
das auch beinahe:

gerhard@precision:~$ sudo hdparm -t /dev/sda1
[sudo] password for gerhard:

/dev/sda1:
Timing buffered disk reads: 1458 MB in 3.00 seconds = 485.66 MB/sec
gerhard@precision:~$

mit 240 GB OCZ Vortex3 SSD. Die Installation der Vortex war ein
größeres Theater mit einigen Firmware-Updates bis es lief.



Und wenn wir schon dabei sind, gleich noch die mitgelieferte 500 GB-Platte:

gerhard@precision:~$ sudo hdparm -t /dev/sdb1
[sudo] password for gerhard:

/dev/sdb1:
Timing buffered disk reads: 100 MB in 0.98 seconds = 102.29 MB/sec


Gruß, Gerhard

[Andreas Erber]

Christian Brandt wrote:

> Jedenfalls muß man bei diesem Rechner erstmal keine SSD zur
> Leistungssteigerung einbauen :-)

Naja der Stromverbraucht dürfte wohl etwas höher sein, der Platzverbrauch
auch. Und der Krach erst! ;)
Wie steht es denn mit den Sysops?

Beste Grüße,
Andy

[Andreas Erber]

Christian Brandt wrote:

> Die meisten SATA-Controller sind intern simpel aufgebaut: Beide
> SATA-Ports werden direkt auf eine PCIE-Leitung gelegt - ergo bekommen
> beide zusammen am Z68 auch nur 250MB/s.

Das kann nicht sein, meine SSD am Z68 und 6G schafft alleine schon über 500
MB/sec.

Beste Grüße,
Andy

[M T r e s s]

Hört sich gut an, da ich aus kostengründen nur die 120 GB SSD hab, ist es
recht eng.
Da das "olle" board (von '07), aber nur 8 Anschlüsse hat, müsste ich einen
Stribe
mit 3 Platten machen, müsste ja gehen, oder?? Oder kann das zu Probs füren.
Bei vier müsst ich dann die 4 Archivplatten auf noch größere 3 reduzieren.

Grüße
Martin


"Gerhard Hoffmann" <dk...@arcor.de> schrieb im Newsbeitrag
news:4f6c9b32$0$6634$9b4e...@newsspool2.arcor-online.net...

[Gerhard Hoffmann]

On 04/01/2012 01:31 AM, M T r e s s wrote:
> Hört sich gut an, da ich aus kostengründen nur die 120 GB SSD hab, ist es
> recht eng.

Die 120er ist vermutlich auch nur halb so schnell, weil nur halb so
viele Speicherchips ihren Datenraten-Beitrag liefern. Bei 256 GB ist
wohl der sweet spot, darüber limitiert dann der Controller oder das
SATA-Interface.

So ist es jedenfalls bei der Samsung 830, die ich diese Woche verbaut
habe um den unten erwähnten CoreDuo auf den gleichen Stand zu bringen
wie die anderen Rechner hier.

Yup. Alle SSD, Asus P8Z68, i7-2600k, 16GB, 570-Graphik,Linux Mint 12,
Oracle Virtual Box für Win, wo's nicht anders geht und die Wartung
beschränkt sich auf das Kopieren einer neuen VM, wenn was kaputtgeht.
Massendaten kommen auf eine extra HD die mit rsync gesichert wird.

> Da das "olle" board (von '07), aber nur 8 Anschlüsse hat, müsste ich
> einen Stribe
> mit 3 Platten machen, müsste ja gehen, oder?? Oder kann das zu Probs füren.

Solange man 1, 2, 4, 8 Platten hat, kann der Controller beim Striping
anhand von 1-3 Bits entscheiden, welcher Platte er den Datenblock vor
die Füße werfen kann. Bei 3 Platten muss er mindestens schieben und
mod 3 rechnen. Kommt darauf an, ob der Programmierer sich die Mühe
gemacht hat. Wetten würde ich nicht drauf.

> Bei vier müsst ich dann die 4 Archivplatten auf noch größere 3 reduzieren.

Archive gehören auf einen anderen Rechner oder eine externe Platte, die
normalerweise im Schrank liegt. Wenn sich Dein Rechner ein Virus
einfängt, dann kannst Du das Archiv-Filesystem auch als infiziert
betrachten. Und wenn der Raid-Controller den Geist aufgibt, versuche
mal, auf ebay genau den gleichen wie vor 5 Jahren zu ersteigern.

Wenn man eine Kopie im Schrank hat, kann man ein RAID für ein
typischerweise selten benutztes Archiv auch nicht mehr wirklich
rechtfertigen.

Gruß, Gerhard

[Andreas Erber]

Gerhard Hoffmann wrote:

> Wenn man eine Kopie im Schrank hat, kann man ein RAID für ein
> typischerweise selten benutztes Archiv auch nicht mehr wirklich
> rechtfertigen.

Intel Chipsatzraid hat jetzt ein Raid_0 von einem ICH7 auf einen Z68 wieder
erkannt. Ich wollte das aber so nicht, weshalb ich nicht geprüft habe ob
dann auch wirklich alle Daten erhalten blieben.

Beste Grüße,
Andy