Test Preiswerte SSDs im Test: Kingston SSDNow V+ gegen G.Skill Falcon II

[Moros]

Das Problem mit der Theorie der Random Reads, die meiner Meinung nach am wichtigsten sind, und der Praxis ist folgendes:
Random Reads sind ja zufällige Lesezugriffe wie sie z.T. bzw. hauptsächlich beim Booten oder bei Anwendungsstarts auftreten. Nehmen wir einmal an Programm X würde nur aus 3 Dateien bestehen, A, B und C. Diese Dateien sind zufällig auf der SSD bzw. den Chips verteilt und alle 4k groß. Der Ladevorgang wäre also abgeschlossen, wenn A, B und C geladen wurden.

In der Theorie könnte man hier eine max. QD von 2 erreichen. Bei einer QD von 2 kann NCQ natürlich nicht viel optimieren. Bei einer QD von 32 oder 64 könnte der Controller bzw. NCQ natürlich mehr optimieren bzw. den Durchsatz erhöhen, ABER! das können aktuelle Systeme (CPU+Chipsatz+RAM) einfach nicht liefern. Deshalb haben wir in der Regel eine QD von unter 10 und deshalb sind die realen Unterschiede zwischen den SSDs bei den Anwendungsstarts so gering. Hätten wir eine Kombi aus Chipsatz+CPU+RAM, die eine hohe QD (durchgängig) liefern könnte, dann würden die Startzeiten fast mit dem theoretischen Durchsatz bzw. den Kanälen skalieren.

Da ich es für unwahrscheinlich halte, dass sich CPUs so schnell in nächster Zeit entwickeln werden, dass man einen rasanten Anstieg der QD hätte, bin ich davon überzeugt, dass jene SSDs am schnellsten sind bzw. sein werden, die die geringste Zugriffszeit und damit den höchsten Durchsatz bei geringer QD bieten.

 

[Eggcake]

Natürlich, das war jetzt rein ohne "QD-Limitierung" vom OS/System aus betrachtet.
Daher rein die Frage "Warum erhöhen sich Random Reads in einem RAID0 (scheinbar, das ist nun ja geklärt) nicht und Random Writes schon?"


Für reale "Power" wäre es wohl derzeit fast am geschicktesten irgendwie Controller mit "breiten" Kanälen zu entwickeln. D.h. dass bereits mit einer QD von 1 eine hohe Geschwindigkeit anliegt. Dürfte wohl eher schwerer sein das umzusetzen

 

[Moros]

Ich denke das lässt sich damit erklären, dass der Controller Random-Write-Anfragen mit zunehmender QD sequentiell anordnet, also aus 4k random writes eigentlich 4k sequential writes macht. Bei Random Reads geht das ja nicht, weil der physikalische Platz, der abgefragt werden soll, schon festgelegt ist.
Im RAID kann der Controller dann sogar sequentiell auf zwei SSDs schreiben.

 

[Onkelhitman]

Dennoch sieht man, dass die eigentliche Performance einer 80GB Intel doch schon ausgehoben wurde. In meinen Augen sieht das so aus, als würde sich ein Raid-0 doch eher lohnen als man dachte.

Jetzt müsste man einen Test haben wieviel das an Auswirkung nach welcher Zeit hat.

Wenn man 10% Leistung in 3 Monaten hat: Für mich ok. Alle 6 Monate neu installieren mach ich eh
GC klappt aber auch im Raid oder? Also muss man dann das TRIM per Hand machen wenn ichs richtig verstanden habe oder? (oder eben bei System-Hoch-/Runterfahren automatisch)

Und viel mehr kostet die Kombi auch nicht als eine 80GB Intel.

 

[Eggcake]

Anand hat's getestet - wenn man rund 10-15GB freilässt (d.h. nicht partitioniert) kann die GC sehr gut arbeiten.

Ich denke das lässt sich damit erklären, dass der Controller Random-Write-Anfragen mit zunehmender QD sequentiell anordnet, also aus 4k random writes eigentlich 4k sequential writes macht. Bei Random Reads geht das ja nicht, weil der physikalische Platz, der abgefragt werden soll, schon festgelegt ist.
Im RAID kann der Controller dann sogar sequentiell auf zwei SSDs schreiben.

Die Erklärung gibt's auf Seite 8, ganz unten

 

[Merlin-.-]

Naja, so ganz kapieren tu ich das alles noch nicht. Aber es ist immer wieder interessant, euch beim Diskutieren zuzuschauen...

Ich hab's heute beim Busfahren auf meinem (Uralt-)Handy noch mal durchgerechnet und RAID 0 ist für mich vorerst wieder vom Tisch. Ich komme mit meiner Milchmädchenrechenweise* auf folgende Kopierleistungen (sequentiell):

Postville 160GB (Preis 380€): 87,5MB/s
2 x SNVP-S2 RAID 0 (Preis 320€): 200MB/s
2 x 1TB "herkömmliche" 5400rpm HDDs (Quelle-Ziel-Setup für schlappe 140€): 70MB/s(?)

In der Praxis dürften die beiden Billigplatten so schnell kopieren wie die teure Postville.
Die zwei SSDNow V+ würden einen Unterschied ausmachen, aber eine Kopierrate auf Niveau der Postville reicht vermutlich schon aus.


*Milchmädchenformel: Copy-Rate = min(Schreibrate, 0.5 * 0.5 * (Leserate + Schreibrate))

 

[Jesterfox]

Wenn das Milchmädchen viel auf die Platten schreibt, vor allem auch sequentiell, dann ist die Rechnung sogar richtig. Das macht man aber eigentlich nur auf Datenplatten und dafür sind SSDs derzeit nicht gedacht.

Als OS und Programm-Speicher ist eine SSD einfach ungeschlagen, da zählt die niedrige Zugriffszeit wesentlich mehr als die Transferraten. Außerdem wird vor allem lesend zugegriffen.

 

[Merlin-.-]

(Die Rechung war für rein sequentiell gedacht)

Joa, haste natürlich völlig Recht.
Witzig ist es aber sicher schon, 500MB/s+ sequentiell zu lesen und zu schreiben.
Aber dafür soooviel Geld raushauen, nooja. Überzeugt mich auch nicht mehr so sehr...

Siehe der Vergleich mit den Billigplatten.

 

[Eggcake]

Also wenn ein RAID0 bei mir verbaut wird, dann auch mit 2 "fetten" SSDs. Imho ist der Vorteil, den man durch 2 "billige" im RAID0 im Vergleich zu einer "teuren" gewinnt zu gering, um die Nachteile von RAID0 zu rechtfertigen.
Also entweder "das doppelte" oder garnix...
z.B. anstatt einer Postville 160GB 2x 80GB reinstecken. Dürfte etwas mehr kosten, dafür hat man auch grob das doppelte.

Ist mir aber noch zu teuer - kommt irgendwann schon noch

 

[Merlin-.-]

Hmm, die V+ (230/180) dürfte sequentiell sogar besser sein als die Postville (250/80)?
Von der GC sollten beide RAID-tauglich sein?

EDIT:
Ein Problem der V+ im RAID0 dürfte das fehlende NCQ werden, da dann selbst die RR mit QD>1 nicht steigen, oder?

 

[Eggcake]

Sofern die aufgestellte Theorie stimmt, ja

Edit: Wobei es natürlich mit QD2 schon steigen kann. Anstatt 1 "Kanal", 2 "Kanäle" weil 2 SSDs. Aber keine Ahnung, müsste man wohl testen :>

 

[Moros]

Funktioniert NCQ im RAID überhaupt? Wird da die Verteilung der Daten nicht über den RAID-Controller geregelt? Ich wüsste ehrlich gesagt nicht, wie NCQ noch gehen sollte, wenn beide SSDs einen Verbund bilden.

 

[Eggcake]

Mh du hast Recht, das sollte eigentlich gar nicht funktionieren. Nur wie erklärst du dir dieselbe Skalierung mit ansteigender QD wie bei einem einzelnen Drive?

Wobei man kaum Werte sieht um das wirklich beurteilen zu können..

 

[Moros]

Vielleicht wird bei QD=0 bzw. 1 immer die gleiche SSD genommen und erst bei höheren QDs werden beide gleichzeitig beschrieben bzw. gelesen. Vielleicht übernimmt der RAID-Controller auch nur die Rolle der SSD-Controller im Bezug auf NCQ. Oder vielleicht arbeitet das Flash-Management des Controllers auch ohne NCQ genauso wie mit NCQ. In der Hinsicht muss ich sagen, habe ich einfach zu wenig Wissen davon wie NCQ und RAIDs genau funktionieren bei SSDs.
Weißt du vielleicht, ob das auch bei HDDs auftritt?

 

[Eggcake]

Ich weiss auch zu wenig darüber Bescheid.

Du hast mich aber auf eine Idee gebracht. Die Stripesize bestimmt ja, ab wann eine Datei gesplittet wird. Diese liegt normalerweise bei 16kb oder darüber, wenn ich recht informiert bin. Das heisst 4kb Dateien werden gar nicht aufgesplittet --> nur eine SSD wird beschrieben/von einer SSD gelesen. Von daher wird evt. in diesem Fall das NCQ der SSD greifen (dickes Fragezeichen).

Das heisst: bei einer QD von 0/1 wird ganz normal von einer SSD gelesen, deshalb auch kein Vorteil. Bei einer QD von 2 wird von beiden SSDs gelesen. Da jedoch auch eine einzelne Intel mit einer QD von 2 doppelt so schnell liest, gibt's hier gar keinen Unterschied. Erst bei hoher QD, wo die Zunahme der Transferrate einer einzelnen SSD abflacht (bei einer X25-M wäre das rund 10-12 - es geht zwar weiter nach oben, aber nur sehr schleppend), werden die Unterschiede sichtbar. Währenddem eine einzelne Intel hier bereits am Limit läuft, sind die Intels im RAID erst "in der Hälfte" angelangt, da der Datenstrom aufgesplittet wird (nicht jedoch die Dateien selber).

Beim schreiben flacht die Kurve viel schneller ab als beim lesen (4k Random Write mit QD=1 ist praktisch gleich schnell wie 4k Random Write mit QD=32). Deshalb werden die Unterschiede auch bei niedriger QD viel schneller ersichtlich.

 

[Moros]

Die Stripe Size, richtig, das könnte es sein. Ist es nicht möglich, dass der RAID-Controller bei einer hohen QD mehrere Random Writes zusammenpackt?

 

[Eggcake]

Ich teste grad was, melde mich in etwa einer Stunde wieder

Ergänzung (8. April 2010)

Ich habe jetzt mit IOMeter meine einzelne X25-M mit verschiedenen Queue Depths getestet.

Zusätzlich habe ich ein RAID0 aus 2 Intel X25-M G2 80GB simuliert. Nach der oben beschriebenen Theorie verhält sich dies unter 4k Random Read wie folgt. Bei einer X25-M dürfte es klar sein. QD1 bedeutet, die SSD arbeitet mit QD1. QD64 ist QD64. Nix neues. Bei zwei SSD verhält es sich folgendermassen:

• Bei QD1: es wird nur eine SSD gleichzeitig genutzt, da ja keine Warteschlange besteht. Es wird nur ein Block gleichzeitig verarbeitet.
• Bei QD2: Es werden zwei Blöcke (d.h. zwei I/O à 4k) gleichzeitig verarbeitet. Das heisst es wird auf beide SSDs gleichzeitig 1 Block übertragen. Das heisst: beide SSDs arbeiten mit QD=1.
• Bei QD3: Eine SSD arbeitet mit QD=2, die andere mit QD=1 (bzw. es wird geswitcht).
• Bei QD4: Beide QD=2
• Und so weiter

Das bedeutet für die folgenden Resultate: die Werte bei X25-M sind gemessen. Die Werte beim RAID0 sind simuliert. QD3 bei 2x X25-M = QD1 + QD2 bei 1x X25-M etc.


4k Random Read, QD 1-6



Eine einzelne Intel skaliert sehr gut mit einer Erhöhung der QD mit. Doppelte QD = (fast) doppelte Transferrate.
Ein RAID0 kann die Transferrate ebenfalls maximal verdoppeln. QD=4 im Raid = maximal 2x QD2 bei einer. Das heisst eine einzelne Intel liegt hier nahe am Optimum, wodurch der Unterschied sehr gering ausfällt.



4k Random Write, QD 1-6


Hier sieht die Geschichte komplett anders aus. Die Intel skaliert verglichen zum Read extrem schlecht mit steigender Queue Depth. Wo es vorhin bei einer einzelnen SSD noch nahezu + 100% an Leistung gab, liegen wir hier bei rund 30% beim Sprung von QD1 zu QD2 - danach ist der Zuwachs nahezu vernachlässigbar!
Somit ist der Unterschied zum RAID, welches die Transferraten zu verdoppeln vermag erheblich.



Soweit zu meiner Theorie. Schauen wir doch mal Anands Resultate mit 2x X25-V an:

4k Random Read QD=3


4k Random Write QD=3



So, und nun schaut euch mal auf meinen Graphen den Abschnitt bei QD=3 an. Na?
Bei meiner Simulation sind's 8% respektive 78%.
Ich weiss, dass es sich um Vs und nicht um Ms handelt, aber das Verhalten dürfte sich ähneln.



In den Links findet ihr noch die Werte bis (nur Stichprobenmässig) einer QD von 64 (will hier nicht alles vollspammen). Erst bei hoher QD wird sich der Unterschied im Random Read in einem RAID0-Gespann bei einer Intel bemerkbar machen. Nicht etwa, weil ein RAID0 so schlecht wäre, sondern weil die Intel bei niedriger QD im lesen von 4k-Blöcken nahezu perfekt skaliert.

4k Random Read bis QD=64
4k Random Write bis QD=64

 

[Merlin-.-]

Nette Simulation!
Klingt auch irgendwie "logisch", dass die QD wie von Dir beschrieben "aufgeteilt" wird, "~50:50".

Demnach sollten die SSDs, die ganz schlecht mit der QD skalieren (allen voran die NCQ-losen), im RAID 0 besser "Random-skalieren" (sequentielle Skalierung ist eh bei allen klar).

Fragt sich noch, wie der RAID Controller die Befehle verteilt. Ob er wohl selbst eine Art "supernatural command queuing" hat? Oder er ordnet die Befehle gar nicht geschickt um (wie bei NCQ), sondern verteilt einfach per FIFO oder ähnlich primitivem Prinzip. (oder nichts von alledem)

 

[Jesterfox]

Erst bei hoher QD wird sich der Unterschied im Random Read in einem RAID0-Gespann bei einer Intel bemerkbar machen. Nicht etwa, weil ein RAID0 so schlecht wäre, sondern weil die Intel bei niedriger QD im lesen von 4k-Blöcken nahezu perfekt skaliert.

Interessante Sachen die ihr hier postet. Nur eine kleine Frage zum Verständnis: So wie ich das sehe liegt das gute Skalieren beim Lesen daran, dass die Postville 5/10 (je nach Modell) Kanäle hat und somit wie ein Raid0 aus 5 oder 10 Platten agiert, richtig?

 

[Eggcake]

Das gute Skalieren dürfte aus einer Kombination der Kanäle und der Arbeit des Controllers liegen. Es ist sehr schwer das eindeutig zu identifizieren, da die Hauptsache wohl nach wie vor der Controller sein dürfte. Da wir keine Ahnung haben wie er in Wirklichkeit arbeitet, will ich jetzt da auch nicht zuviel hineininterpretieren.

Ich habe einen interessanten Beitrag entdeckt. Wenn ihr des englischen mächtig seid...dürfte auch einiges Beantworten auf die Frage hin, mit welcher Queue Depth ein OS so arbeitet. Die Antwort: es ist völlig abhängig vom benutzten Laufwerk...


Achtung, WALL OF TEXT INCOMING!

Hui, alles perfekt erklärt, wenn man vorsichtig liest und langsam versucht zu verstehen . Ist übrigens derselbe, der bei Anand in die Comments gepostet hat (vorige Seite).
von hier: http://www.xtremesystems.org/forums/showpost.php?p=4323291&postcount=132

QD, IOPS, access time, and block size of random access.

The smallest block size the file system operates with is the cluster size. For NTFS this defaults to 4KB.

Flash SSDs also (normally) operate with 4KB as their base block size.

QD = Queue Depth. This is the number of outstanding IOs towards storage, unanswered requests if you like. The OS may send as many requests it wants at the same time, but for the SSD to be able to utilize this it needs to support NCQ (native command queue) and the drivers and HBA (SATA controller between CPU and SSD) must also support it. NCQ allows an SSD to receive up to 32 requests at the same time and process them internally in the fastest possible way, regardless of the order they were received.
SSDs have multiple flash channels, Indilinx Barefoot and Samsung based SSDs have 4, intel x25-M has 10. The number of channels is the same as the number of requests the SSD can answer in parallel. If the _momentary_ queue depth, this is the number of requests sent in a burst plus unanswered requests waiting in the SSD, is f.ex. 6, an x25-M can answer ALL requests in parallel and have NONE outstanding, while Vertex can answer 4 of them in parallel and have 2 outstanding, and then answer the 2 outstanding when 2 of the previous requests have finished. As you can see, an x25-M is likely to have a lot lower number of unanswered requests waiting than Vertex, and as such the QD shown in the OS will likely be lower for x25-M.

The OS will show AVERAGE QD between each update, and not momentary like i mentioned in the example above. An average QD above 1 shown in the OS means the storage is not able to answer requests faster than they arrive and has a backlog. However, the maximum momentary QD may be several times the average QD when bursts of small requests are sent. In these cases an SSD with more channels can utilize more channels and finish the job faster, given each of the channels is as fast or faster than the competition. This is where we begin to talk IOPS.

IOPS = IO operations per second, or requests per second if you like. The maximum number of IOPS an SSD can do theoretically is equal to the number of channels times IOPS per channel. IOPS per channel is 1/[average access time in seconds]. Most MLC SSDs can do about 5000 IOPS per channel, but the scaling when working in parallel on multiple channels gets limited by the controller that has to administrate and match the outstanding requests with the channels that can answer them.

An Vertex with 4 channels can do 5000 IOPS with QD=1, and about 16000 IOPS with QD=5 (QD > channels to ensure none of the outstanding requests are on the same channels, which would cause one channel to be unused). Increasing the QD further has no effect on vertex since all 4 channels are already saturated and deliver max performance. As you notice, 16000 is less than 4x5000, the 4000 IOPS missing is because of the time the controller needs to administrate and match requests to channels.

An x25-M with 10 channels can also do 5000 IOPS with QD=1, and about 18000 with QD=5 (at which point MAXIMUM 5 channels are in use), but scales further to about 30-32000 IOPS at QD=12 (at which point most channels are in use), and can reach up to 40000 IOPS at QD=32 (it varies with setups from 32-40K).

By adding more drives in RAID, you increase the number of channels available to answer requests in parallel. By RAIDing 2 Vertex, you have 8 channels that can answer up to 8 requests in parallel. This means a 2 R0 vertex can do roughly 30-32000 IOPS at QD=10 when all channels are saturated.
RAIDing 2 x25-Ms will give you 20 channels, so you would need over QD=20 to saturate them, but when that happens, you can answer up to 70-80000 4KB random read requests per second.

With larger random read blocks, the x25-M uses all it's 10 channels to split the larger blocks up into 4KB blocks, like RAID. Or at least something like this. Because of this, it can answer 8KB blocks faster but fewer in parallel, and you end up with 5 8KB blocks in parallel at almost 4KB access times. 2,5 16KB blocks in parallel, and 1,25 32KB blocks (meaning it can do 1 32KB block + 1 4KB block, even if that 4KB is the first part of a new 32KB block). You get the point. By adding more x25-Ms in RAID, you can answer more larger block random requests in parallel, and at the same time you decrease the chance that requests will be to the same channel, which causes witting for the previous to finish. Adding more SSDs in RAID like this also reduces the organisational workload on each SSD controller when QD gets high and results in lower access times when QD gets higher.

The CPU like you know operates at Gigaherz, finishing operations in nanoseconds. Level 1 cache has a few ns access time, L2 cache has very low double digit ns access time, L3 cache has a bit higher double digit ns access time, then you get to RAM that has very roughly 50ns (+- 20ns or more). As you can see, the CPU has to wait very few cycles for it's internal cache, and some when it needs data from RAM.

When the CPU needs access storage, things change dramatically. Hard drives have access times around 10-15ms, this is 1 million times slower than L2 and L3 cache. Meaning it has to wait millions of cycles for data to arrive.
With SSDs you get access times normally in the area of 0,1ms (for single 4KB requests). 0,1ms = 100µs, roughly 2000 times longer access times than RAM and 10000 times L2-L3 cache. Still, a LOT lower than 1 million.

Das bestätigt imho auch mehr oder weniger die durchgeführte Simulation...es stehen im Prinzip schlicht die doppelte Anzahl an Kanäle zu verfügung, gleichzeitig werden die Requests so aufgeteilt, dass die SSDs gleichmässig belastet werden. Da der Controller mit zunehmender QD immer mehr zu macht, erhöhen sich die IOPS auch schneller, da die einzelnen SSDs (d.h. die einzelnen Controller) auch weniger belastet werden.