[Sammelthread] Sind die Werte meiner SSD in Ordnung? (Teil IV)

  • Ersteller Ersteller jodd
  • Erstellt am Erstellt am
Status
Für weitere Antworten geschlossen.
Das Nadelöhr ist PCIe x1 mit dem der Marvell an den Chipsatz angebunden ist.
Häng die SSD an den Intel-Kontroller (graue SATA-Anschlüsse) und schau Dir dann nochmal die Werte an.
 
Hallo Krudas,

das Nadelöhr ist der Marvellcontroller und dessen Anbindung mit nur einer PCIe Lane, dadurch kommt da nicht mehr zustande. Dein Board hat ja aber zwei Sata 3 Anschlüsse am Intelcontroller, schließe die SSD dort an und die Geschwindigkeit passt.
Den Marvellcontroller kannst du, wenn du ihn nicht brauchst, im Bios deaktivieren, dann bootet dein System auch etwas schneller.
 
Aye ... ich danke euch vielmals für eure schnellen Antworten, das wars ... wer kann das denn erahnen dass die Kombination nicht passt die Asus da eingebaut hat?

Hab sie jetzt auf den SATA3-Controller umgelegt und die Werte sind da, wo ich sie gerne hätte :D

Nochmals danke!

Schönen Gruß aus Kölle,
Krudas
 

Anhänge

  • as-ssd-bench SAMSUNG SSD 830  29.08.2012 21-30-16.png
    as-ssd-bench SAMSUNG SSD 830 29.08.2012 21-30-16.png
    39,2 KB · Aufrufe: 626
Also es geht mit einem Marvel durchaus auch schneller, wenn man das Glück hat und ein Marvel 9182 auf dem Mainboard sitzt. ;) Ich habe sechs SSDs im Rechner, zwei davon sind Crucial m4, die im Raid 0 am Marvel laufen. Ist vom Speed her im praktischen Alltag zu den Intelports nicht zu unterscheiden, auch wenn die Werte in Benchmarks natürlich etwas schlechter sind. Ich schreibe mit ca. 370 MB/s auf die beiden M4s, was in etwa der Leistung der beiden M4s im Singelbetrieb entspricht - mal zwei Bilder anbei.

Triller
 

Anhänge

  • Marvel9182Raid0-m4.JPG
    Marvel9182Raid0-m4.JPG
    111,2 KB · Aufrufe: 520
  • Raid.JPG
    Raid.JPG
    126,1 KB · Aufrufe: 498
Zuletzt bearbeitet:
Der 9182 hat ja auch zwei PCIe Lanes, nur ist der eben sehr selten mal irgendwo auf einem Board zu finden und auf keiner PCIe Karte verbaut. Zumindest wäre mir keine bekannt. Das gleiche gilt auch für die Marvell 88SE9220, 88SE9230 oder 88SE9235, die über zwei PCIe Lanes verfügen.

Ob das RAID 0 aber sinnvoll ist, musst Du selbst entscheiden. Die Datenraten sind nicht so viel besser als eine einzelne SSD auch schaffen kann, die ja lesen ja mit 500MB/s an einem nativen SATA 6Gb/s Controller. Wenn die das auch am 9182 schaffen, wäre es ggf. sinnvoller die einzeln zu betreiben und so die Zugriffe zu verteilen. Dann wird ehr nur von einer SSD gelesen und das kaum langsamer als vom RAID, aber Du hast wieder TRIM.
 
Das ist schon ok und soll auch so sein. Meine beiden M4s dienen nur als noch als Datengrab für gößere temporäre Videofiles und für die Games, und ja, natürlich ist das Raid 0 für mich sinnvoll, sonst würde ich es nicht machen. Da mir die beiden 128er M4s einzeln zu langsam schreiben, ist das Raid 0 hier eben vollkommen ok und in die Tonne kloppen wollte die M4s noch nicht, auch wenn mir meine beiden Vertex 4 an den Intelports wesentlich besser gefallen, eben weil sie wesentlich schneller schreiben - und bitte, jetzt keine Aufkärung zu OCZ und wie schlecht sie doch sind, ja ich weiß, auch die Vertex 4 ist total schlecht, ich kann es aber nicht mehr lesen - ich bin mit meinen beiden Vertex 4 (eine 128er und eine 256er) äußerst zufrieden und sie laufen ebenfall seit Monaten ohne ein Problem mit meinem X79 Brett!:D

Wie gesagt, im Alltag gibt es keinerlei gefühlten Unterschied zu den Intelports, Trim ist wurscht, die GC der M4s ist vollkommen ok, Trim ist im Alttag eines normalen Anwenders eh total überbewertet! Die beiden M4s laufen jetzt schon seit Monaten im Raid 0 und sind noch so schnell, wie frisch getrimmt, das System idelt jeden Tag lange genug (wie bei den meisten), dass die GC arbeiten kann, also no problemo. Eine einzelne M4 performt am 9182 wie im angehangenen Screen, wie gesagt, sie schreiben mir einzeln in der 128er Verson aber mittlerweile zu langsam - Crucial sollte mal langsam eine Nachfolgegeneration bringen. ;)

Wollte auch nur zeigen, Marvel kann eben auch schneller.
 

Anhänge

  • M49182.png
    M49182.png
    38,8 KB · Aufrufe: 534
Zuletzt bearbeitet:
Triller, die GC kann nur soviel Platz aufräumen, wie für den Controller frei ist. Das sind ohne TRIM eben nur die LBAs die noch nie beschrieben wurden und mit TRIM eben alle, die auch im Filesystem frei sind. Solange Du also nicht mehr am Stück schreibst als wie für den Controller frei ist, kannst Du das auch mit der vollen Geschwindigkeit machen. Da Windows aber die Eigenschaft hat die Dateien mit der Zeit immer mehr für den ganzen Adressraum zu verteilen und dabei nur den Bereich ausspart, der für den MFT reserviert ist (normal nur 12.5%, das ist aber in der Registry einstellbar und wird dann beim Formatieren berücksichtigt) kann das mit der Zeit eben immer weniger werden und wenn sie einmal ganz voll wird, dann sind es von da an nur noch die 5 bis 6% ab Werk.
 
Danke für die Aufklärung, dann wissen die anderen wenigstens bescheid.;) Dennoch ändert es nichts an der Tatsache, dass es im praktischen Alltag ohne Relevanz ist. Ich schreibe eigentlich täglich mehrmals 20 - 30 GB große Files auf die beiden M4s, seit Monaten, ohne das sie langsamer schreiben würden - es wird immer mit ca. 370 - 380MB/s geschrieben, ich wiederhole mich, seit Monaten - aller Theorie zum Trotz.

Also die Benches und die graue Theorie einfach mal beiseite lassen und die SSDs einfach nur nutzen, so halte ich es zumindest - es wird für den Normalo oder semiprofessionellen Einsatz sowieso viel zu viel gelabert über SSDs, meistens total unnützes und unnötiges Zeug, da wie gesagt in der Praxis oft ohne Relevanz - ich nutzte meine SSDs lieber, als sie totzulabern! :)
 
Zuletzt bearbeitet:
nabend leute,

ich habe jetzt eine woche mein system auf einer crucial m4 128gb am laufen und wollte nochmal nachfragen ob die werte so ok sind.
ich habe 2 screens der eine (m4 1) ist wenn das system normal gestartet wurde und alles galaden ist und der andere (m4 2) wurde gemacht nachdem origin,steam,icq,aida und afterburner beendet wurden.
was mich wundert ist das die leserate fällt wenn die progs aus sind.
greetz dapoly
 

Anhänge

  • m4 1.jpg
    m4 1.jpg
    93,5 KB · Aufrufe: 546
  • m4 2.jpg
    m4 2.jpg
    98 KB · Aufrufe: 519
Hallo,

heute auch meine Crucial M4 128GB eingebaut.
BS drauf gespielt und alle nützlichen Programme die ich brauche.
Vor der inst. auf AHCI gestellt. SSD hängt am 1. Sata Anschluß.

Aber, die Werte sind glaube ich nicht ganz in Ordnung oder?

Es ist zwar nur Sata2 aber dennoch sehe ich hier Werte die weit über dem liegen was ich habe.
Kann mir jemand evtl. helfen?

 
Habe eben selber nochmal im Bios geschaut und hast recht gehabt. Da gabs nochmal was mit AHCI.
Habe das jetzt auch darauf gestellt und neugestartet.
Jetzt mit diesem Ergebnis:



Er hatte nach dem Start von Windows direkt irgendwelche Treiber installiert. Dann nochmal neustart gemacht.

Immer noch net perfekt oder?

Edit:

Was ist dieses LMP und wie kann man das deaktivieren? Bringt das überhaupt was?
Alles komplett Neuland für mich sry für ganzen Fragen.
 
Zuletzt bearbeitet:
Triller schrieb:
Dennoch ändert es nichts an der Tatsache, dass es im praktischen Alltag ohne Relevanz ist. Ich schreibe eigentlich täglich mehrmals 20 - 30 GB große Files auf die beiden M4s, seit Monaten, ohne das sie langsamer schreiben würden - es wird immer mit ca. 370 - 380MB/s geschrieben, ich wiederhole mich, seit Monaten - aller Theorie zum Trotz.
Nicht aller Theorie zum Trotz! Ich habe doch geschrieben, was da passiert und die 20 bis 30GB sind noch total im Rahmen. Das passt eben noch in den Platz, den Windows für den MFT reserviert und nur dann anderweitig beschreibt, wenn sonst nichts mehr frei ist (plus den Freien Platz der SSD, was nochmal so 10GB ausmachen sollte). Das RAID ist nie voll gewesen, der Bereich wurde nie überschrieben (es wurde auch nur mit der Schnellformatierung formatiert) und damit ist das ein Freier Bereich für den Controller. Wenn Du das mal bis zum Anschlag füllst, dann kannst Du nur noch so 10GB schnell schreiben, weshalb man in so einen Fall ja eben besser einen Teil von der Größe unpartitioniert lässt (aber im Neuzustand oder nach Secure Erease!) wie man eben so im Stück schnell schreiben möchte, also bei Dir 30GB. Dann hat der Controller immer genug freien Platz der er Aufräumen kann, weil man diese unpartitionierten Bereich nicht versehentlich füllen kann.

Triller schrieb:
es wird für den Normalo oder semiprofessionellen Einsatz sowieso viel zu viel gelabert über SSDs, meistens total unnützes und unnötiges Zeug, da wie gesagt in der Praxis oft ohne Relevanz - ich nutzte meine SSDs lieber, als sie totzulabern! :)
Das stimmt, es wird da viel Unsinn verbreitet, aber ganz ohne Wissen um die Vorgänge kommt bei Leuten wie Dir dann irgendwann der Moment, wo sie z.B. das RAID mal komplett vollmachen, einfach mal normal formatieren oder eine Suche nach defekten Sektoren starten und danach nur noch so 10GB schnell schrieben können. Dann werden falsche Schlüsse gezogen und die SSD wird nieder gemacht oder gleich reklamiert, dabei kann der Controller dann garnicht anders reagieren. Obendrein haben die Leute scheinbar auch noch recht, denn mit den neuen SSDs ist das RAID ja wieder schnell, bis es mal wieder komplett voll gemacht wird und dann sind wieder die SSDs schuld. Am Ende heißt es dann, die Dinger taugen nichts und gehen viel zu schnell kaputt :evillol:

Dabei kann man das alles erklären bzw. vermeiden, wenn man etwas Verständnis für die Technik hat.

dapoly schrieb:
eine (m4 1) ist wenn das system normal gestartet wurde und alles galaden ist und der andere (m4 2) wurde gemacht nachdem origin,steam,icq,aida und afterburner beendet wurden.
was mich wundert ist das die leserate fällt wenn die progs aus sind.
Da hat wohl irgendwas anderes auf die SSD zugegriffen, das ist doch sicher Dein Systemlaufwerk. Beobachte mal im Resourcen Monitor was da alles auf der Disk passiert, wenn die Porgramme beendet werden (aber genau so wie voeher, also Booten und gleich Programme beende, etc.) mache den Test ggf. einige Zeit nach dem Beenden der Programm erneut, wenn keine Aktivität mehr auf der Disk ist. Die Systemlaufwerke werden ja dauernd von allen Möglichen Diensten angesprochen, da sind zuverlässige Tests sowieso Glückssache. Wenn da ein Programm bzw. Windows nach Update sucht oder irgendwelche Datei beim Beenden noch mal reorganisiert oder löscht, dann kann da schon mal einiges an Aktivität sein, nachdem der Bildschirm schon geschlossen wurde. Man sieht das auch im Task Manager, wenn man die entsprechenden Spalten auswählt was ein Programm so liest und schreibt und auch, wie lange einige Programm auch nach dem Schlissen des Fensters noch laufen.
 
Musst wohl immer das letzte Wort haben, was Holt! ;) Habe zu deinen Ausführungen aber im Grunde nicht mehr viel zu sagen, bist hier im Forum eben der Theoretiker vor dem Herrn, meine ich aber nicht böse, diese Aussage!

Recht hast du dennoch weiterhin nur in der Theorie, in der Praxis hat das, was du beschreibst, und was Inhaltlich ja auch nicht falsch ist (ich kenne mich ebenfalls bestens aus), aber trotzdem kaum bis wenig Relevanz, es passiert zumindest in meinem Alltag einfach nicht so, wie du es beschreibst - evtl. Trimt der Marvel im Raid ja doch - Zauberei!;) Dein zweiter Absatz ist aber echt wirres Zeug, was du da schreibst, vor allem klingt es sehr überheblich! Ich habe auch öfter mal Renderfiles in Größen von 150 GB! Was meinst du, wie oft ich das Raid schon bis zum Anschlag voll gemacht habe, so dass nur noch ca. 1,5 GB frei waren und trotzdem passiert das alles nicht, wie du es in deinen Ausführungen beschreibst - ich schreibe bereits kurz nach dem Löschen der Daten wieder mit 370GB/s - ich wiederhole mich irgendwie und lasse es jetzt aber auch gut sein!:o
 
Zuletzt bearbeitet:
Triller schrieb:
Habe zu deinen Ausführungen aber im Grunde nicht mehr viel zu sagen, bist hier im Forum eben der Theoretiker vor dem Herrn, meine ich aber nicht böse, diese Aussage!
Eine Theoretiker der aber 10 SSD von 5 Hersteller und 7 Modellen im Einsatz hat (hatte nachdem die OCZ Vertex2 tot ist sind es noch 6 Modellreihen von 4 Herstellern: Intel X-25V, Crucial C300/m4, Samsung 470/830 und Plextor M3). Ein bischen befasse ich mich auch praktisch mit den Dingern :D

Triller schrieb:
Dein zweiter Absatz ist aber echt wirres Zeug, was du da schreibst, vor allem klingt es sehr überheblich!
Sorry, aber das ist einmal die Erfahrung aus den Foren, wo es oft vorkommt, dass jemand ein Problem hat, welches mit der SSD überhaupt nichts zu tun hat. Hätte er eine HDD verbaut (bekannte Technik), so würde er dort nie das Problem vermuten. Nun hat er sich aber erstmals eine SSD gegönnt und plötzlich ist die erstmal für jedes Problem der Hauptverdachtige. Und sei es nur der Klassiker mit dem verschundenen Speicherplatz (Windows versteckte Dateien), der hier jede Woche mal auftaucht, obwohl es bei HDDs nicht anders ist.
Triller schrieb:
Ich habe auch öfter mal Renderfiles in Größen von 150 GB! Was meinst du, wie oft ich das Raid schon bis zum Anschlag voll gemacht habe, so dass nur noch ca. 1,5 GB frei waren und trotzdem passiert das alles nicht, wie du es in deinen Ausführungen beschreibst - ich schreibe bereits kurz nach dem Löschen der Daten wieder mit 370GB/s - ich wiederhole mich irgendwie und lasse es jetzt aber auch gut sein!:o
Auch das ist kein Wunder und auch kein heimliches TRIM. Lies mal in Anandtechs Review der Plextor M5Pro die Seite "Performance Over Time & TRIM" durch. Da wird die zuerst mit HD Tach ganz beschrieben:

Clean_575px.PNG


Das gibt die "vollen" Perfomance, wobei HD Tach wohl auch recht kleine Blockgrößen beim Schreiben verwendet, sonst wäre da mehr drin. Dann wurde die SSD nochmal seq. beschrieben und für 20 Minuten mit Random Schreibzugriffen belastet:
Dann hat er das ganze wiederholt aber die Random Zugriffe 60 Minuten lang gemacht, was dazu führt, dass die Zuordnung von LBA und Flashadressen noch mehr durcheinander gewürfelt sind.
Lagen vorher die zusammenhängenden LBAs auch in relativ gut zudsammenhängenden Flash Adressen, so sind die nun noch mehr für die Flashblöcke verstreut. Damit werden beim seq. Überschreiben einer Menge LBAs viel öfter nur wenige Pages in einem Block ungültig, was ja immer dann passiert, wenn ein LBA entweder überschrieben oder getrimmt wird, wobei TRIM im Test deaktiviert ist.
Die GC muss nun also laufend Blöcke zum Löschen auswählen, in denen noch viel mehr Pages gültige Daten enthalten als vorher, wo ja beim Überschreiben reihenweise Pages des gleichen Block ungültig wurden, weil die Zuordnung von LBAs zu Flashadressen nicht so konfus war. Damit müssen jetzt auch vor dem Löschen des Blocks viel mehr Daten intern kopiert werden, was einmal mehr Zeit kostet und zum anderen die vorher gelöschten Blöcke wieder viel stärker mit den alten Daten füllt, also das erneute und zeitraubende Löschen eines Block wieder viel früher, also nach viel weniger geschriebenen Daten erforderlich macht. Es können also nun weniger Daten schnell in den nun kleineren noch freien Teil eines vorher gelöschten Blocks geschrieben werden und es dauert länger bis der nächste Block gelöscht ist, weil mehr zu kopieren ist.

Aber auch das ist nicht das Ende vom Lied, denn eine gute FW, wie sie auch die Crucial m4 hat, erkennt die Situation und räumt die Daten wieder soweit als möglich auf.
Und wenn Du Dir nun hier den linken Teil der Kurve ansiehst, dann erkennst Du, dass die Schreibrate fast genau auf den 350MB/s wie am Anfang beginnt und für etwa 8 GB auch dort bleibt. Das ist der Freie Bereich, also der Unterschied zwischen den GiB (1024^3 Byte) NAND Kapazität und den Gb (1000^3 Byte) Nutzkapazität abzüglich der Verwaltungsdaten. Diesen hat der Controller im Idle mehr oder weniger komplett freigeräumt und kann nun entsprechned viele GB auch wirklich schnell schreiben.

Das habe ich auch im zweiten Artikel gemeint und den Bereich kann man vergrößern, wenn man eben im Neuzustand (bzw. nach einem Secure Erease) einen Teil der Kapazität unpartioniert lässt. Außerdem sieht man hier auch, wie die Tiefpunkte der Schreibratenkurve immer mehr ansteigen, weil eben im dem zunehmenden Überschreiben der LBAs in den jeweils gelöschten Blöcken immer weniger Pages noch gültigen Daten enthalten. Es wird also weniger kopiert und damit weniger Kapazität der vorher gelöschten Blöcke wieder mit alten Daten belegt.

Lässt man nun 20GB unpartitioniert, so verschiebt sich der erste Abfall der Schreibrate auch um 20GB nach rechts und damit allen auch die Tiefpunkte weniger dramatisch aus. Hat man die SSD außerdem nur seq. gefüllt und dann wieder mit einer seq. Datei überschrieben, so wie es bei Dir der Fall ist, dann ist das ganze noch viel harmloser, wie man schon im Vergleich der beiden Kurven, also der nach 20 Minuten Randim und nach 60 min Random Schreiben auf der vollen SSD sieht. Das ist ein Unterschied von 169MB/s zu 49MB/s im Durschnitt!! Bei Dir sind es 0 Minuten Random und dazu kommt vermutlich noch Zeit für die GC, die das ganze nochmal so aufräumt, dass die ersten 5 bis 10GB sowieso mit voller Geschwindigkeit gehen! Dann sind 20 bis 30GB mit 370MB/s (die GB/s werte ich mal als Tippfehler, die schafft ja nicht einmal das RAM auf den schnellsten Grakas mit 512Bit Anbindung) auch kein Wunder für zwei SSD im RAID 0 die i.d.R. jede auf fast 200MB/s bei ASS-SSD kommen. Crucials Angabe von 170MB/s schreibend ist bekanntlich sehr zurückhaltend und Benchmarks mit 200MB/s bei der m4 128GB findest Du genug hier im Forum.

SSDs die in dem Test so eine Kurve zeigen, sind auch gut für den Einsatz ohne TRIM geeignet und die m4 ist seid der 009er FW sowieso eine der Besten davon (die Leserate ist übrigens schon am Limit von HD Tach, das ist halt kein Tool für SSDs):
Hier werden sogar direkt nach der Folter mit den 4k Radom Schreibzugriffen (auch wenn bei der 20 Minuten schon gereicht haben und Plextor erst nach 60 Minuten Folter am Boden war) auf die volle SSD der Abfall der Schreibrate erst nach einigen GB erfolgt, da ging die Plextor schon auf dem Zahnfleisch. Dann sieht man auch deutlich, wie die Schreibrate langsam aber stetig ansteigt. Da Anand den Test damals anders durchgeführt hat, fehlt der Vergleich nach einer halben Stunde im idle für die Idle-GC, aber bei einen zweiten seq. Schreiben sieht es so aus und man erkennt klar, dass seq. Schreiben wie weniger auf die Performance geht als wenn man die volle SSD mit Randim Schreibzugriffen belastet:
m4-0009-2ndpass_575px.png

Aber ich kann nun wirklich nicht bei jedem Beitrag auf alle Details eingehen, sonst werden die alle so lang wie dieser, das liest dann kaum einer und die paar die es lesen, verstehen es wieder nicht.
Triller schrieb:
Musst wohl immer das letzte Wort haben, was Holt! ;)
Nach klar doch :D Nur weil Du die Theorie nicht verstehst, ist sie noch lange nicht falsch! :evillol: Vielmehr erklärt sie immer noch, was Du in der Praxis siehst. :D

Wer von sich selbst behauptet er kenne sich ebenfalls bestens aus, der sollte besser nicht solche dummen Sprüche klopfen, denn wenn einer in der Runde ist, der wirklich Ahnung hat (und den gibt es im Leben früher oder später immer), läuft er tierisch auf und danach glaubt ihm niemand mehr. Das ist jetzt nicht persönlich gemeint, wir sind ja hier unter uns und keiner weiß, wer wir wirklich sind, aber ich habe schon zu viele solcher Schlauberger kommen und schnell wieder gehen gesehen, denen keiner eine Träne nachgeweint hat. Anders sieht es dagegen bei denen aus, die sich bemüht haben zu verstehen, wie man die Theorie praktisch anwendet und im Zweifel auch mal klar sagen, wo ihre Grenzen sind statt Aufgaben zu übernehmen, denen sie nicht gewachsen sind und an denen sie dann scheitern. Aber das ist am Thema vorbei und nur mal so zum nachdenken!
 
Zuletzt bearbeitet:
Holt, du hast ein echtes Problem, lasse dir mal helfen!:freak: Dein Geschreibe bleibt auch weiterhin total unwichtig und ist ohne Relevanz in meinem Fall, du verstehst eben nicht, was sich sagen wollte, lese meinen ersten Beitrag hier in diesem Thema noch mal genauer durch! Toll finde ich aber, das du alles gibst, leider stellst du dich zumindest bei mir mit deiner Überheblichkeit vollkommen ins Abseits, kommst daher leider total unsympathisch rüber, obwohl du zweifelsohne Ahnung hast!:king:
 
Zuletzt bearbeitet:
Hi,

ich habe die Sammelthreads zu den SSD-Werten bereits überflogen und wollte nun mal meine Werte checken lassen. Ich habe als Mainboard das Gigabyte 790FXTA-UD5 und muss folglich den Marvell 9128 Chip für SATA3 verwenden.
Wie ich dem Thread bereits entnehmen konnte, kann ich damit nicht auf die maximalen Leistungen hoffen.
Die SSD hängt am SATA3-Port und AHCI ist aktiviert. Bei der SSD handelt es sich um eine Samsung 830 mit 256GB Speicherplatz.

Danke für eure Hilfe :)
 

Anhänge

  • as-ssd-bench SAMSUNG SSD 830  01.09.2012 09-45-30.png
    as-ssd-bench SAMSUNG SSD 830 01.09.2012 09-45-30.png
    39,4 KB · Aufrufe: 522
  • as-ssd-bench SAMSUNG SSD 830  01.09.2012 09-33-34.png
    as-ssd-bench SAMSUNG SSD 830 01.09.2012 09-33-34.png
    39,4 KB · Aufrufe: 529
Hallo,
passen die Werte meiner Samsung SSD 830 mit SATA2 so?
 

Anhänge

  • as-ssd-bench SAMSUNG SSD 830  02.09.2012 13-05-31.png
    as-ssd-bench SAMSUNG SSD 830 02.09.2012 13-05-31.png
    39,2 KB · Aufrufe: 530
Status
Für weitere Antworten geschlossen.
Zurück
Oben