Solid State Drive (SSD) (Part 4|2)

[barzefutz]

weil im Unterschied zu einer Festplatte kein Lesekopf irgendeine Bewegung machen muss.

Ich glaube du hast meine Frage immer noch nicht verstanden... Die Zugriffszeit einer SSD ist nicht null, nur weil sie keinen Lesekopf hat
Ich würde gerne wissen warum eine SSD bei random Zugriffen mit kleinen Datenmengen langsam ist, beim Zugriff auf fragmentierte Daten aber nicht. Das muss doch irgendwie erklärbar sein.

wir hatten afaik nicht mal geklärt ob eine defragmentierung bei einer ssd technisch überhaupt realisierbar ist

schließlich gibt es wearleaving verfahren , die auch ruhende daten umkopieren um weniger benutzte zellen "frei" zu geben...
von daher kann eine ssd nicht lange defragmentiert sein...

Hmmm... von der Existenz eines solchen Verfahrens wusste ich bisher nichts. Hast du einen Link dazu? Wäre es nicht eher kontraproduktiv wenn die SSD von sich aus dauernd Daten hin- und herschaufelt? Wear Leveling schön und gut, aber es sollen doch unnötige Schreibvorgänge vermieden werden. Zumindest ist das die Maxime von Intel, zu deren Controller ich einiges gelesen habe.

 

[rompen2k4]

in diesem punkt gibt es nichtmal bei den herstellern einigkeit, also zerbrecht euch noch nicht den kopf darüber. ocz sagt, für die mlc zellen sei es schädlich, mtron sagt, für die slc zellen sei es gut, etc pp.

ich empfehle hierzu einfach mal den wikipedia-artikel über ssds, auch wenn er natürlich nur sehr kurz dieses thema anschneidet, dürften hier dann viele fragen wegfallen und bereits geklärt sein, wenn man sich alles durchliest. http://de.wikipedia.org/wiki/Solid_State_Drive

 

[barzefutz]

antiram: Was ist ein "Request"?

also inwiefern unterscheidet sich darauf bezogen ein 4k random read Benchmark über 100 mb mit dem Lesen einer 100 mb großen Datei die vom Dateisystem in 4k-Blöcke gehackt wurde?

 

[M.D. Geist]

Hmmm... von der Existenz eines solchen Verfahrens wusste ich bisher nichts. Hast du einen Link dazu? Wäre es nicht eher kontraproduktiv wenn die SSD von sich aus dauernd Daten hin- und herschaufelt? Wear Leveling schön und gut, aber es sollen doch unnötige Schreibvorgänge vermieden werden. Zumindest ist das die Maxime von Intel, zu deren Controller ich einiges gelesen habe.

hatte der eine datenrettungs-ceo erklärt glaub ich...

weswegen es so schwer ist bei ner ssd daten wiederherzustellen, weil man nicht genau sagen kann wo die daten nach X tagen liegen...

und natürlich wäre es nich kontraproduktiv!

Einfachstes Beispiel : du hast ne ssd fast gefüllt... Sollen jetzt nur die <5% Zellen beschrieben werden die noch frei sind?
Stattdessen schaufelt er im hintergrund einmal um und du hast wieder die XX gb zur verfügung.
Die Zellen sollen ja gleichmäßig abgenutzt werden, was jede defragmentierung unsinnig erscheinen lässt

 

[barzefutz]

Einfachstes Beispiel : du hast ne ssd fast gefüllt... Sollen jetzt nur die <5% Zellen beschrieben werden die noch frei sind?

Das klingt natürlich logisch
Andersherum dürfte er die Daten aber auch nicht _allzu_ oft rumschaufeln, ich meine was bringt es wenn alle Zellen immer genau gleich ausgelastet sind, aber dafür alle 5 Sekunden beschrieben werden? Naja wahrscheinlich muss man da ein gutes Mittelmaß finden. Sooo genau in die Materie wollt ich auch gar nicht gehen, mich interessiert das bloß mit der Zugriffszeit (Benchmark vs. Fragmentierte Datei lesen)

 

[antiram]

antiram: Was ist ein "Request"?

also inwiefern unterscheidet sich darauf bezogen ein 4k random read Benchmark über 100 mb mit dem Lesen einer 100 mb großen Datei die vom Dateisystem in 4k-Blöcke gehackt wurde?

Dass bei kleinen Dateien (bzw. Anfragen, Requests) jedes mal neu verhandelt werden muss. Das ist so wie wenn Du 6 mal zum Bäcker gehst um jeweils 1 Brezel zu holen, obwohl 1mal gehen und 6 Brezeln holen viel schneller geht.

Hier wird ansatzweise erklärt wie die Defragmentierung bei ssd laut apacer funktionieren soll:
http://downloads.diskeeper.com/pdf/HyperFast.pdf
als Video:
http://www.diskeeper.com/products/documentation/video-Diskeeper2.asp

 

[AristoChat]

tja ...

Random/Sequential hängt von den Programmen die ihr benutzt. Eine Datebank wird meist > 90% random mode benutzen.

Aber bei unseren windows OS's auch relativ viel random zugegriffen.

NTFS Standard Clustergrösse ist 4 kB egal ob Sequential oder Random.

Bitte nicht denken dass sequentiel schneller ist als random wenn auf ein Bit zugegriffen wird ... das Gegenteil ist meist der Fall (Random > Sequential) in diesem spezielen Fall.
Aber bei grossen Dateien ist sequential generel viel schneller.

Bei Sequential Read/Write werden die Bytes nach und nach gelesen/geschrieben. Das heisst sie folgen sich.
Beim Lesen/Schreiben erzielt man dadurch die beste performance.
Dabei wird nur ein Zeiger inkrementiert.

Bei Random ist es ganz anders ... Daten die man lesen / schreiben werden nicht mit Hilfe des Zeigers zugegriffen.
Jeder Zugriff nimmt Zeit in Anspruch.

Einfach vostellen ihr hab eine Reihe äpfel und gebt eine Tritt.
Bei Sequential werden alle Äpfel abrollen ... da alle in einer Reihe positioniert sind.
Bei Random müsst ihr jeden einzelnen Apfel einen Tritt geben ... viel mehr Arbeit.

Wenn ihr einen bestimmten Apfel treten wollt kann Random Mode viel schneller sein

Bei Ram (Random Access Memory) ist der Effekt der gleiche ... also nicht nur an SSDs bezogen.

Inwieweit random mode optimiert ist auf der SSD ist schwer zu sagen denn das hängt von vielen Parametern und Hardware/Software Optimierungen.

Beim Schreiben ist der Effekt noch schlimmer denn nicht nur 4kb werden gelöscht sondern ein ganzer block > 64 kB und Wearleveling wird zur Last.
Dann muss die Map geupdatet werden (initialize locks) ... daten gelöscht .. Map update (set lock+write) ... neue daten drauf ... Map update (release lock + write) .. dh da wird in bestimmten Fällen ein vielfaches der Daten neugeschrieben.

Darum sollte man prinzipiel auf journalised filesystems bei SSDs verzichten wegen dem höheren workload und ausserdem Block bezogen (implementiert) sein und nicht MTD. Ext2 , ext3 haben eine MTD implemetierung also nicht optimal.

Wie man sieht hat man bei Random viel mehr Workload als Sequential bei SSDs .. ich sehe da nur als Möglichkeit einen grösseren Cache, mehr Känale und gezielte Software Optimierungen (aber daür müssen die heutigen FS angepasst werden) um bei SSDs den Write Random werte zu trimmen.

MFT und Intel/Micron zeigen was möglich ist ... vieles wird aber noch viel besser werden nächstes Jahr vielleicht nicht billiger aber dafür leistungsfähiger.

Ich könnte die Sachen villeicht besser erklären aber Deutsch ist nicht meine Muttersprache

 

[Mot]

Weiss jemand ob Mtron auch Garantie auf Laufwerke ohne Kaufbeleg gibt (Gewinnspiel usw.)?

 

[little-oak]

@Aristo

Ich danke Dir,für deinen Post!
Von allen Posts, die hier in den letzten Monaten verfasst worden sind,ist das meiner Meinung nach der Sinnvollste und Informativste .

Bitte mehr davon !

Gruss
little-oak

 

[USAR]

Weiss jemand ob Mtron auch Garantie auf Laufwerke ohne Kaufbeleg gibt (Gewinnspiel usw.)?

wenn du das Teil nach Korea schickst vielleicht schon, aber der Händler in Deutschland der die Gewährleistung bieten muss, wird das nicht tun. Da musst du es schon dahin bringen wo du es herhast

 

[Thinkpaduser]

@ barzefutz: mit Request ist ein IO gemeint. Warum bricht ne SSD beim random Lesen ein: Du forderst aus deinem Filesystem einen 4kByte großen Datenblock an. Dieser liegt aber in Wirklichkeit auf einer sogenannten Page der NAND's die z.B. 128KByte groß sind.
D.h.: damit dir die SSD 4kByte gben kann muss sie intern 128kByte holen. Wenn Du das komplett random machst, werden bei 4kByte Blöcken aus 100Mbyte/s -> 3,2Mbyte/s, umgekehrt kannst du jetzt die IO-Leistung der SSD errechnen, 100MByte/128kByte = 800, da es innerhalb einer Sekunde passiert. Natürlich hat die Fragmentierung der Daten auch bei der SSD eine "gewisse" Auswirkung, diese ist im Gegensatz zur HDD nur fast nicht zu spüren. Es wurde hier mal ganz nett beschrieben: 1000Dateien/Fragmente HDD 12 ms -> 12 Sekunden Positionierzeit, SSD 0,1ms -> 0,1 Sekunden Positionierzeit. Den Unterschied zwischen 0,1 und 0,2 ms Positionierzeit werden wir wohl nicht merken

 

[Snoopy69]

Das 5 1/4" ist ja nicht nur die Platine, sondern mit Gehäuse und Kabelei^^.
Und das RAM ist furtz-Egal. Ich hab halt altes Infineon genommen das rumliegt. Wird sowieso durch den Chipsatz ausgebremst. Ist wie DDR3 in ein FSB-System stecken. Nicht das RAM ist der Flaschenhals^^.

2GB-Riegel sollen (vielleicht) gehen hab ich irgendwo mal aufgeschnappt, aber zu der Zeit wo das I-Ram aktuell war gabs sone Riegel einfach nicht, und auch heute wird es wohl schwer sein sowas aufzutreiben^^

Hm, schwer aufzutreiben nicht (ist ja verfügbar). http://geizhals.at/deutschland/?cat=ramddr&xf=253_2048~256_1x
Aber davon gibt es scheinbar nur diese bei GH.

Ich kann ja mal neben den 4x 1GB noch 4x 2GB ordern.
Falls es nicht geht müssen sie halt zurück.

Oder reichen 4GB für swap und Kleinkram?

 

[HisN]

Mir persönlich reichen sie.

 

[AssassinWarlord]

Nabend... was meint ihr, bringt der Hardware Raid Controller von Highpoint, der RocketRaid 3120 mit 128MB DDR2 etwas mit zwei Mtrons im raid 0?

das ist eine PCIe x1 Controller, was anderes geht bei mir nicht rein. nun frage ich mich nur, ob so ein hardware raidcontroller nicht besser währe, als mein Pseudo Intel ICH Raid was eh nur software ist ?

bzw. ob sich das lohnt der kauf des raidcontrollers, ob ich da eine veränderung spüre (gut, die bootverzögerung zwecks initialisierung kann ich in kauf nehmen)

 

[barzefutz]

@ barzefutz: mit Request ist ein IO gemeint. Warum bricht ne SSD beim random Lesen ein: Du forderst aus deinem Filesystem einen 4kByte großen Datenblock an. Dieser liegt aber in Wirklichkeit auf einer sogenannten Page der NAND's die z.B. 128KByte groß sind.
D.h.: damit dir die SSD 4kByte gben kann muss sie intern 128kByte holen. Wenn Du das komplett random machst, werden bei 4kByte Blöcken aus 100Mbyte/s -> 3,2Mbyte/s, umgekehrt kannst du jetzt die IO-Leistung der SSD errechnen, 100MByte/128kByte = 800, da es innerhalb einer Sekunde passiert. Natürlich hat die Fragmentierung der Daten auch bei der SSD eine "gewisse" Auswirkung, diese ist im Gegensatz zur HDD nur fast nicht zu spüren. Es wurde hier mal ganz nett beschrieben: 1000Dateien/Fragmente HDD 12 ms -> 12 Sekunden Positionierzeit, SSD 0,1ms -> 0,1 Sekunden Positionierzeit. Den Unterschied zwischen 0,1 und 0,2 ms Positionierzeit werden wir wohl nicht merken

Danke dir und AristoChat, sehr gut erklärt
Das mit der internen Blockgröße hatte ich ganz außer acht gelassen. Das müsste also heißen dass wenn eine Datei auf Dateisystemebene in viele 4k-Blöcke fragmentiert ist, die SSD die Daten trotzdem intern auf "ganze" 128k-Blöcke verteilt, oder? Und dadurch im Gegensatz zum random benchmark schneller gelesen werden kann.

 

[Kabelmaster]

Ja genau das soll das heißen.
@Assassinwarlord ich kenne den Highpoint nicht, kann aber sagen das meine Patriot Warp V2 am Dell Perc5/i mit einer Stripesize von 128KB richtig aufgelebt hat. Noch nie gesehene Werte .

MfG Kabelmaster

 

[AristoChat]

Das müsste also heißen dass wenn eine Datei auf Dateisystemebene in viele 4k-Blöcke fragmentiert ist, die SSD die Daten trotzdem intern auf "ganze" 128k-Blöcke verteilt

Genau .. darum haben die meisten SSDs schlechte Werte im Random Mode bei kleinen Dateien.

Random Read kann man noch boosten aber Write ist komplex.

Wie ich vorhin gesagt habe ... nehmen wir an die Datei ist 4kB gross aber der Block ist 128kB.

Spezialfall Löschen:
Der ganze Block wird gelöscht um die kleine Datei zu löschen und neugeschrieben (restliche Dateien ) ... Wearleveling macht zur gleichen Zeit auch sein Teil de Arbeit.

In nächster Zukunft werden die Blockgrössen in den SSDs kleiner werden ... im Moment geht es nicht besser weil die Zugriffszeit darunter leiden würde.

Zauberwort : Latency

Darum sind RAM-SSD noch unangefochten ... aber iofusion kommen den schon näher.

Die SSDs könnten viel schneller sein aber die PC interfaces sind einfach zu mittelalterlich oder an Kompatibilität happert es.

Mit der Areca 1231ML ist bei 8 * Mtron 7000 Schluss ... interfaces müssen viel besser werden .. net normal dass die Evolution stagniert.

Lasst euch nicht blenden :

STR ist wichtig aber mehr als 300 MB/s braucht kein "normales" Programm ... ausser Kopieren Tag und Nacht oder mega grossen Dateien laden/kopieren/bearbeiten.

Aber Latency/Zugriffszeit werdet ihr sofort bemerken ... ein schlechter Wert und alles wirkt lahm ... für das OS oberste Priorität.

Beispiel :

1000 Dateien à 10kB löschen

bei einer Mobi ... schön lahm Anschein die SSD würde blockieren
bei einer 7500 ... geht munter voran .. bei der Memoright GT bestimmt sehr gut
bei i-ram ... ritsch ratsch
bei violin ram-ssd ... pschiiii .. A single 2U Violin 1010 can deliver over 3 million random IOPS... latency im microSekunden Bereich .. tja ganzes Programm.

ok ist ein spezieler Anwendungsfall darum gibt es ja "noch" Unterschiede zwischen den beiden Technologien (RAM / FLASH)

Mann muss sich nur bewusst sein dass es im Moment Einschränkungen gibt .. die in ein paar Jahren bestimmt nicht mehr existieren.

Die Geeks werden versuchen die beiden Technologien zu kombinieren .. die Reichen nehmen nur das beste (vorausgesetz sie sind informiert) ... die anderen die weit weniger Geld haben werden warten .. manche werden billig kaufen und sich ärgern ... andere billig kaufen und Kompromisse eingehen die sie selbst akzeptieren/definieren - tja ...

 

[M.D. Geist]

ich bin sowieso der meinung, dass die uns zurückhalten...
bei den heutigen ddr2 ram preisen kann mir keiner sagen, dass es unmöglich ist eine paar gb große sektion auf dem mainboard fürs os oder temp sachen zu reservieren...

ram das seine daten behält ist ja theoretisch auch möglich (memristor oder so)
zu doof, dass intel und amd ihre prioritäten wo anders hinlegen... noch jedenfalls (intel hat ja immerhin angefangen)

 

[Nightspider]

Wo liegt denn das Fusion-iO mit seinen Zugriffszeiten und wie groß sind diese bei RAM und SLC / MLC SSDs?

Meint ihr das man noch nen Unterschied spürt, zwischen Flash und RAM von den Zugriffszeiten?

Eigentlich nur beim Kopieren von richtig großen Ordnern mit kleinen Dateien oder?

Bei SSDs ist doch ne Datei auch sofort geöffnet, zB. ein Bild beim Doppelklick.

Kann mir das zumindest als non-SSD Besitzer net vorstellen das es dann noch viel schneller geht...

 

[Kabelmaster]

Mich würde der RocketRaid 3120 auch mal interessieren, gibt es niemanden der diesen Controller hat?

MfG Kabelmaster

 

[AristoChat]

Kann mir das zumindest als non-SSD Besitzer net vorstellen das es dann noch viel schneller geht...

bei RamSSD ist jede "Aktion" flüssig
bei FlashSSD abhängig von der Applikation

RAM = ns

Iodrive = +/- 50 uS aber dafür volle bandbreite ... wegen optimierter interface Anbindung (pcie *4)
SLC = 100-600uS
MLC SSDs = >400uS und ausserdem meist schlecht designt (das eigenliche Problem)

Alles eine Frage des Geldes und der Performance die jeder für sich braucht ... no limit dann ganz klar RamSSD sonst FlashSSD.

Was nützen 10 raptoren in raid0 wenn eine ramssd noch schneller ist auf Bezug auf die Zugriffszeit ?

Nicht vergessen dass ein schlechter Write Wert ein sehr guter Read Wert niedermetzeln kann ... dieser Punkt wird meist vergessen ... aber das ist wiederum nicht so einfach herauszufinden wie (oft) und wann auf die SSD geschrieben wird . (DiskMon - sysinternals hilft )

 

[Nightspider]

bei RamSSD ist jede "Aktion" flüssig
bei FlashSSD abhängig von der Applikation

Ne Idee was das für Applikationen sein könnten, wo man mehr Speed durch den Ram hat?

Gamer bzw. Gamer-PCs fallen da sicher raus...da merkt man bestimmt keinen Unterschied mehr zwischen SSD und RamSSD. (Okay vllt minimal an den Ladezeiten)

 

[Dott]

Ne Idee was das für Applikationen sein könnten, wo man mehr Speed durch den Ram hat?

Gamer bzw. Gamer-PCs fallen da sicher raus...da merkt man bestimmt keinen Unterschied mehr zwischen SSD und RamSSD. (Okay vllt minimal an den Ladezeiten)

guck dir mal das hier an, bezieht sich zwar nur auf den Systemstart aber, das wird wohl durch die Bank so sein.

http://de.youtube.com/watch?v=EwjNcMwVyxk

 

[AristoChat]

Ne Idee was das für Applikationen sein könnten, wo man mehr Speed durch den Ram hat?

Gamer bzw. Gamer-PCs fallen da sicher raus...da merkt man bestimmt keinen Unterschied mehr zwischen SSD und RamSSD. (Okay vllt minimal an den Ladezeiten)

Hängt davon ab wie oft Maps geladen werden.

Datenbanken, Enterprise Applikationen und OS wo einfach die Latenz/access time gefragt ist.

Oft wird vergessen:

RAM SSDs haben symmetrische read/write IOPS. Da ist "meist" nicht der Fall bei Flash-SSDs.

Falls du ein bisschen Zeit hast hier stöbern:

http://www.storagesearch.com/ssd-ram-v-flash.html

 

[M.D. Geist]

http://www.computerbase.de/news/hardware/laufwerke/flashspeicher/2008/oktober/gskill_25-ssds_128_gb/


Und ein neuer im markt der flotten Flasher...

Die zwei SSD-Speicher liegen in einer Größe von 2,5 Zoll vor und bieten dem Käufer eine Kapazität von 64 oder 128 GB. Als Flash-Speicher kommen beim Schreiben langsamere, dafür aber günstigere MLC-NAND-Chips (Multi-Level-Cell) zum Einsatz. Die SSD-Platten werden an eine SATA-II-Schnittstelle angeschlossen und bieten nach eigenen Angabe eine sequenzielle Leserate von 155 Megabyte pro Sekunde, während die Schreibrate bei 90 MB/s liegt. Die Zugriffszeit beträgt in etwa 0,2 ms.

 

[anticucho]

konkurrenz belebt das geschäft

 

[DaReal]

Sehr schön .. je mehr da auf dem Markt rumreiten je günstiger wirds und je schneller geschehen große Schritte auf dem Sektor

Wobei ich hoffe, dass sich auf dem ioFusion- und iRAM-Markt ebenfalls noch etwas tut ...

 

[M.D. Geist]

iofusion/iram haben halt das problem nicht für laptops einsetzbar zu sein... was derzeit bei den ganzen ssds nen hauptgrund ist...

Marketingbla wie : Schnelleres Arbeiten, weniger lärm, weniger hitze, stoßresistenter, längere Akkulaufzeit, höhere Mobilität , usw zieht bei PCI / PCI-E karten leider nicht! =(

 

[USAR]

ich habe schon mal gehört, dass die Intel einbricht, wenn Sie voll geschrieben ist, aber das sie so langsam werden soll, hätte ich nicht gedacht. Hast du Benches?

 

[Mechkilla]

@schweiger:

Bleib bitte mit deinem Problem nur in einem Thread (d.h. nur im Intel-Thread und nicht auch noch hier). Sonst gibt das ein zu großes durcheinander.

Danke, Mechkilla