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

Status
Für weitere Antworten geschlossen.
nein, es verkürzt nur die lebenzeit ;)

soviele leute haben ja noch keine ssd's, ich denke trotz der nun 92 seiten haben wohl grade mal ca. 10 leute hier die teile aus mtron fabrikation. davon min 3-4 an areca, dh. wenn hier mal eine platte hier im forum mucken macht dann ist auch die chance hoch das es einen areca betreiber trifft :d
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
wenn die zugriffzeit konstant bei ca. 0.1ms steht sehe ich nicht den sinn einer defragmentierung.

abgesehen davon haben die platten doch ein system eingebaut was dafür sorgen soll das die einzelnen datenzellen gleichmäßig oft beschrieben werden um die lebenzeit zu verlängern. da wäre defragmentieren gradezu gift - abgesehen davon würde mich interessieren ob ein defrag programm überhaupt diesen mechanismus überbrücken kann.
 
Natürlich bringt der defrag was, sogar MASSIV, vergleich doch mal die Datenrate der SSD beim random data access und bei sequential read/write.

Gruss,
MP
Dann mach halt weiterhin schön fleißig Defrags... :d
Ich hatte das Thema schon vor ein paar Wochen in CB aufgegriffen (warte noch auf Antwort von Barolo). Ich denke, dass du mit einem Defrag "Wear-Leveling" umgehst, da ein Defragmentierungs-Programm ja Dateien an einem Stück schreiben will. So würden dann auch schwache, vielfach beschriebene Zellen gezwungenermaßen beschrieben werden, obwohl "Wear-Leveling" diese erstmal ausklammern würde.

Hast du Benches von einer stark fragmentierten und einer defragmentierten SSD? Die würde ich gerne mal sehen... ;)

@ Barolo

Wieder eine Spezial-Frage für dich... :d
Bei einer leeren HDD werden Dateien ja an einem Stück geschrieben. Bei einer leeren SSD müsste "Wear-Leveling" die Dateien fragmentiert schreiben, wenn diese schon stark in Gebrauch gewesen war, oder? ;)


Kennt jmd ausser HDtune ein Programm mit dem ich Online (also unter Windows) Sektoren prüfen kann? Ich hätte zugerne dieses Programm, das die Ingenieure von MTRON benutzen :(
 
Zuletzt bearbeitet:
Hi Snoopy69,

wolltest Du nicht die Ergebnisse aus den Posts #2604,#2605,#2608# und #2612 auf die 1.Seite zusammenfassen? Kennst Du jemanden, der die Mtrons an einem ICH8 am laufen hat? Wenn ja mit welchem Ergebnis?

Eddie
 
Hallo,

ich hab mich auch hinreissen lassen und hab mir eine MOBI 3025 bei Winkom bestellt.

Einfach spitze das Teil. VistaX64 startet superschnell und auch die anderen Anwendungen ist praktisch auf Click sofort verfügbar.

Hier meine Ergebnisse:

1x MTRON SSD MOBI 3025 32GB, an Gigabyte P35 DQ6:
ICH9R - Mode: IDE; H2testw: 68/71 MB/s (lesen/schreiben), HDTach: 80 MB/s,
HDTune: 77MB/s; bootet einwandfrei

JMICRON - Mode: IDE; H2testw: 69/91 MB/s (lesen/schreiben), HDTach: 100 MB/s, HDTune: 96MB/s; bootet einwandfrei

An beiden Controllern wäre AHCI prinzipiell möglich, jedoch ist die MOBI an beiden "schnachlangsam" -> 4MB/s!!?? Gibt es da eine Erklärung dafür?

Bei der täglichen Arbeit ist der o.a. Geschwindigkeitsunterschied nicht bemerkbar.
Ich habe die MOBI aber trotzdem am JMICRON angeschlossen.

Grüßle Trio33
 
Hast du Benches von einer stark fragmentierten und einer defragmentierten SSD? Die würde ich gerne mal sehen... ;)

Beweisen oder nur massives Wunschdenken ??

Na was passiert denn wohl mit dem datendurchsatz beim lesen/schreiben wenn für jedes Teil fragment ein load von 0.1ms dazu kommt?

Hier, MacBook (ICHR7) mit einer MTRON 32GB Mobi unter MacOS (=BSD Unix derivat) mit XBench:

http://db.xbench.com/merge.xhtml?doc2=237570

Sequential Uncached Write 45.50 MB/sec [4K blocks]
Random Uncached Write 5.46 MB/sec [4K blocks]


Performance Unterschied sequential (am stück) und random (fragmentiert) Faktor 10. Beweiss genug?

Beim Read fällt der Unterschied geringer aus, ist aber immer noch vorhanden und wird um so größer je größer die Anzahl der Fragmente, d.h mit größeren Datenmengen würde auch der Read immer weiter auseinander driften. Um das zu erkennen braucht man aber nicht mal eine Benchmark, sondern kann man bereits im Datenblatt lesen.

Der Random Access Time Faktor gibt ganau die Latzenz an welche den unterschied zwischen einem Sequential und Random Datenzugriff beschreibt.

Solange dieser nicht null ist, hat man bei jedem Fragment eine verzögerung um diesen Wert, was den Durchsatz (=gelieferte daten in einer gewissen zeitspanne) entsprechend senkt. Nicht immer nur mit irgentwelchen parameter um dich werfen, sondern bitte auch mal versuchen zu verstehen :)

Gruss,
einen sonnigen Sonntag wünscht
MP
 
Zuletzt bearbeitet:
Zuletzt bearbeitet:

So, ich habe jetzt Daten vom XBENCH Benchmark vorgelegt der zwischen Sequential und Random write/read unterscheidet und bei der SSD einen unterschied beim schreibebn vom Faktor 10 ausmacht, beim lesen geringer ist, aber immer noch vorhanden ist.

Wo bitte ist denn dein Benchmark?

Wollen wir hier über FAKTEN oder über Theorien Diskutieren. Ich habe FAKTEN vorgelegt. Nun bist du am Zug.

Ausserdem würde mich mal brennend deine Definition des Paramteters "Latzenz" bei den SSD Laufwerken interessieren, wenn nach deiner Therorie Random und Sequential Daten gleich schnell geliefert werden. Wenn das der Fall währe müsste der Faktor Null sein.

Gruss,
MP
 
Zuletzt bearbeitet:
Du sollst 2 SSDs vergleichen! Nicht eine

Vergleich den IO von einer defragmentierten SSD zu einer fragmentierten SSD !

Dass SSDs bei 4k random write schwächeln (ohne cache) weiß hier jeder!

Nun bist du am Zug.
 
ach je jo Leute ...

Wearleveling hat nix mit Sequentiel oder Random zu tun .. ist einfach ein Mechanismus um die Haltbarkeit zu erhoehen.

Sequentiel ist einfach die Staerke der SSD .. in Random ist die Leistung eher schwach.
(Durch Aid0 wird dieser Nachteil allerdings gut ausgebuegelt)

Die SSD zu defragmentieren ist SCHLECHT da ihr dabei das Wearlealing zwangslaeufig aktiviert.

Ein Weg wie man diesen Nachteil korrigiert ist es einen Treiber zu nutzen der Random- in Sequentialschreiben umformt .. und schon ist alles OK


Sonne draussennnnnnnnnnnnnn :)
 
Zuletzt bearbeitet:
Sequentiel ist einfach die Staerke der SSD .. in Random ist die Leistung eher schwach.

iometerread.jpg


Verwechselst du da nich was ?
 
Also ich spreche von "Schreiben"

im Lesen haben Festplatten keine Chance ...
 
Zuletzt bearbeitet:
Du sollst 2 SSDs vergleichen! Nicht eine

Vergleich den IO von einer defragmentierten SSD zu einer fragmentierten SSD !

Dass SSDs bei 4k random write schwächeln (ohne cache) weiß hier jeder!

Nun bist du am Zug.


Wassn fürn blödsinn, warum sollte ich zwei verschiedene SSD´s miteinander vergleichen. Äusserst wissenschaftlich. LOL

Ich vergleiche den schreib/lese vorgang von einer Datei auf einer leeren SSD. Mal schreibe/lese ich die am stück (Sequential = Defragmentiere SSD) und mal schreibe/lese ich die gleichen Daten verteilt (Random = stark fragmentierte SSD).

Dabei ergibt sich beim schreiben einen Datendurchsatz unterschied vom Faktor 10 beim schreiben und ein etwas kleinerer beim Lesen. Siehe XBENCH results.

Wo sind nun deine für jeden nachvollziebaren Benchmark Results die deine Therorie stützen? Wir warten immer noch gespannt!

Gruss,
MP
 
Zuletzt bearbeitet:
Hallo,

ich hab mich auch hinreissen lassen und hab mir eine MOBI 3025 bei Winkom bestellt.

Einfach spitze das Teil. VistaX64 startet superschnell und auch die anderen Anwendungen ist praktisch auf Click sofort verfügbar.

Hier meine Ergebnisse:

1x MTRON SSD MOBI 3025 32GB, an Gigabyte P35 DQ6:
ICH9R - Mode: IDE; H2testw: 68/71 MB/s (lesen/schreiben), HDTach: 80 MB/s,
HDTune: 77MB/s; bootet einwandfrei

JMICRON - Mode: IDE; H2testw: 69/91 MB/s (lesen/schreiben), HDTach: 100 MB/s, HDTune: 96MB/s; bootet einwandfrei

An beiden Controllern wäre AHCI prinzipiell möglich, jedoch ist die MOBI an beiden "schnachlangsam" -> 4MB/s!!?? Gibt es da eine Erklärung dafür?

Bei der täglichen Arbeit ist der o.a. Geschwindigkeitsunterschied nicht bemerkbar.
Ich habe die MOBI aber trotzdem am JMICRON angeschlossen.

Grüßle Trio33

Nicht so optimale Werte, aber es ist ja allgemein bekannt, dass der ICH9R nicht so gut mit den SSDs zusammenspielt.
 
Hi,
bin ich hier der erste mit einer MTRON Mobi SSD mit einem Defekt?

Weil das bisher keiner beantwortet hat: Nein, Du bist hier nicht der erste. HisN hatte als erster 2 defekte Mobis gemeldet. Beide liefen an einem Areca. Und AristoChat hatte auch von solch einem Fall aus einem französisch sprachigem Forum berichtet. Daher auch die folgende Frage:
Areca und SSD vertragen sich wohl nicht so gut ?
Was an sich schade ist, da die SSD an den Arecas eine ziemlich gute Performance erreicht haben.

Zum Thema "Sequential/Random Write" was:

Ich glaub man sollte genau betrachten was da gemacht wird. Wenn diese Benchmarks bei einem Random Write Daten eines bestehenden Flash-Blocks (teilweise) ändern, so muß die SSD diesen erstmal auslesen, die Daten ändern, den Block löschen und dann neu schreiben (eventuell in einen anderen). Das kostet Zeit. Wenn die SSD die Daten direkt in einen leeren Flashblock schreiben kann, dann wird man Werte bekommen, die an die max. Schreibrate rankommen (dürfte bei den Benchmarks, die sequential writes testen der Fall sein).
Begründen lässt sich das mit der unterschiedlichen Größe der Flash-Blöcke und der von den Benchmarkprogrammen verwendeten Blöcke.

Mechkilla
 
Sequential Uncached Write 45.50 MB/sec [4K blocks]
Random Uncached Write 5.46 MB/sec [4K blocks]

ich hab kein Problem damit ... ok ... ist ja bekannt

Um dieses Problem aus dem Weg zu schaffen benutzen ja viele hier AID0 ... und das funktioniert "sehr" gut

Was an sich schade ist, da die SSD an den Arecas eine ziemlich gute Performance erreicht haben.

ja aber es ist der erste Fall ... daraus so schnell Schlussfolgerungen zu ziehen halte ich nicht gut
 
Zuletzt bearbeitet:
Wassn fürn blödsinn, warum sollte ich zwei verschiedene SSD´s miteinander vergleichen. Äusserst wissenschaftlich. LOL

Blablabla, hier mal für dich, das du sicher nicht mit deinem nondefrag/defrag Mist erklären kannst :

nondefrag-crys4d7.jpg


Man beachte den UNENDLICHEN Unterschied zwischen Seq Read und 512k RANDOM/DEFRAGGED Read !

Faktor 10 gelle ?

Nö, voll net, bei meinem USB Stick ist er worstcase beim schreiben quasi Faktor 1000 !


Bin grad am defraggen meines USB Sticks via windoos tool, hab grad leider keine mobi/pro zur hand... :shot:
 
Zuletzt bearbeitet:
Areca 1210 + 3 * Mtron 16GB (Stripe size 64kB) => Aid0

520993704.jpg
;) (+/- 114MB/s ist ja schoen oder ? )
 
Zuletzt bearbeitet:
Aristo: vergess net ... der Areca hat nen netten Cache ... der "kaschiert" die schlechte Random Write Leistung der SSDs dann doch etwas.

Mechkilla
 
Wo sind nun deine für jeden nachvollziebaren Benchmark Results die deine Therorie stützen? Wir warten immer noch gespannt!

Wieso wir eigentlich? Eigentlich nur Du, aber hier sindse dennoch, damit du endlich ruhe gibst :

Testsystem :
Dell Inspiron 8600
PYN Attache USB Stick 8gig

Stick ausgangs situation :


Nondefraged Stick :
nondefrag-attobon.jpg
nondefrag-crysfie.jpg


=> Seq Read und 512k Random read sind identisch ! :lol:
Extreme random schreibschwäche bei kleinen files, ist uns allen bekannt und ein Manko der Nand technologie


Defraged :


Defrag Benches nochmal :
defrag-attoxnx.jpg
defrag-crystalil1.jpg


=> Seq. wurd sogar weniger! :lol: Wieder war 512k Random read schneller als seq read :lol:
Von Faktor 10 keine Spur :lol: :lol:


Fazit : Defraggen bei USB Sticks ist schonmal banane...
Null Speedvorteil.

Wenn man wieder drauf schreiben wird, wird der Stick probleme bekommen, da er keinen schreibcache besitzt.

Ohne MFT gibts keinen Speedvorteil...

Lesespeed ist immer noch gleich, da wirste keinen Unterschied feststellen, ansonsten siehe och Aristos Werte :xmas:

Nicht einverstanden? Dann mach deine eigenen Benchmarks und zeig uns wie dein System vom Defraggen nen speedvorteil kriegt! Und stützt dich nich auf sinnlose Theorien.


P.S. Mit Truecrypt ist random write in der Praxis schneller! Bedeutend sogar, aber da mir das kein Benchmark prog bestätigen kann, glaubt mir das ja eh keiner... :hwluxx:
 
Bei einer Verschlüsselung hängt die Datenrate von der CPU ab. Je aufwändiger die Verschlüsselung, desto aufwändiger und langwieriger die Berechnung durch die CPU. Der SSD ist es doch egal, ob sie nur Nullen, nur Einsen oder ein Misch-Masch davon schreibt.

Nochmal wegen Defragmentierung...
Bei einer SSD gibt es keine mechanischen Bauteile, die die Latenzen ich die Höhe treibt. Ob die SSD schön zusammenhängende Dateien liest/schreibt oder ob die Dateien fragmentiert sind, die SSD kann auf weitentfernte, nicht-benachbarte Sektoren genauso schnell zugreifen, wie auf Benachbarte. Bei einer HDD müsste man jedoch die Zeit dazurechnen, die der Schreib-/Lesekopf braucht, um auf weit entfernte Sektoren zuzugreifen. Das ist ja das Gute an SSDs.


@ Aristo

Müsste das nicht mehr sein bei 3 SSDs? Was sagt der HDtach-Bench (mit schreiben)?
Und überhaupt - müsstest du nicht in Irland sein, Schafe hüten? :d
 
Zuletzt bearbeitet:
Schreiben von kleinen files wurd enorm beschleunigt.
Das war mir die Hauptsache...
 
Ich dachte, dass du alles erst sammelst und ich es dann eintrage.

Hi,

verstehe ich jetzt nicht. In den aufgelisteten Posts von mir sind doch die Ergebnisse aufgeführt. Soll ich diese jetzt in einer priv. Email an Dich zusammenschreiben und Du kopierst sie dann hinein? Bitte kurze Info an mich, wie Du es Dir vorstellst.

Eddie
 
Zuletzt bearbeitet:
Nach ich dachte, dass du so eine Liste machst. Sowas wie hier zb...

http://www.forumdeluxx.de/forum/showthread.php?t=415418

Muss nicht bunt sein, aber so hatte ich mir das vorgestellt. Du lässt es mir dann per PN oder Mail zukommen und ich kopiere es in Post #1.
Ansonsten müsste ich jeden Post erst suchen und die Infos einzeln rauskopieren - evtl. sogar noch den Text formatieren. So war das aber nicht von mir gedacht.
 
Zuletzt bearbeitet:
Status
Für weitere Antworten geschlossen.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh