SSDs und Zugriffszeit

bartio

Commander
Dabei seit
Apr. 2008
Beiträge
2.499
Hallo,

weil ich einer meiner Intel 80GB G2 in einem anderen Gerät brauche, habe ich mir eine Intel G2 120GB als Ersatz gekauft.
Soweit ist alles einwandfrei.

Nur wundere ich mich das die Lesen-Zugriffszeit bei der neuen bedeutend höher ist als bei der "alten" 80er.
Nun ist dieser Unterschied (siehe Screenshots) nun nicht spürbar, nur wundere ich mich wie eigentlich baugleiche SSDs in dem gleichen System (gleiche Hardware und gleiche Software durch Imagerückspielung) so unterschiedliche Zeiten kreieren können (100% langsamere Zugriffszeit ;)).
Dachte immer Flashspeicher innerhalb einer Serie wären nahzu gleich ;)

ciao und noch ein schönes (warmes) WE :D
 

Anhänge

  • aaaa.JPG
    aaaa.JPG
    61,2 KB · Aufrufe: 1.113
  • Unbenannt.JPG
    Unbenannt.JPG
    60,3 KB · Aufrufe: 977

lazy74

Lt. Commander
Dabei seit
Okt. 2008
Beiträge
1.219
Beim Schreiben sind sie ja beide ziemlich gleich.

Hast du den test bei der 120GB mal wiederholt? Vielleicht lief da irgendwas unbemerkt im Hintergrund (Virenscan), was das Ergebnis beeinflusst hat
 

mastermc51

Lieutenant
Dabei seit
Dez. 2008
Beiträge
620
Was ihr nur habt, sind doch vollkommen normale Werte!
Meine OCZ Vertex 2 Ext. 120GB liegt sogar noch etwas über deiner 120 GB Intel.
Alles bis knapp 0,2 ms ist NORMAL!
 

bartio

Commander
Ersteller dieses Themas
Dabei seit
Apr. 2008
Beiträge
2.499
Einige Male habe ich den Test durchlaufen lassen. Egal ob vor oder nach dem Neustart. Die Zugriffszeit bleibt konstant bei dem angezeigten Wert. ;)
 

Eggcake

Commodore
Dabei seit
Juni 2007
Beiträge
4.827
Benutze mal z.B. HD Tune mit Random Access.

Die Zugriffszeit wirkt sich nur auf den Zugriff auf 512B aus, was relativ selten vorkommt. Anders gesagt:
20MB/s 4k Random und eine Zugriffszeit von 0.1ms sind genau gleich performant wie 20MB/s 4k Random und 1ms Zugriffszeit [bei 512B].

Genau erklären kann ich den Unterschied aber auch nicht - Auswirkungen auf die Performance hat das aber so gut wie keine.
 

Holt

Banned
Dabei seit
Mai 2010
Beiträge
59.527
Die Zugriffszeit an sich kann man doch garnicht messsen, denn bei einer SSD gibt es diese ja eigentlich nicht mehr richtig. Bei einer HDD war das ja die Zeit zum Positionieren der Köpfe und Erreichen des Sektors und wenn man dann nur einen Sektor liest, so ist die Zeit für den Transfer der Daten vergleichsweise gering und wird vernachlässigt. Da HDDs aber Cache haben und diesen gerade beim Schreiben kleiner Datenmengen auch gerne einsetzen, findet man immer wieder mal Testergebnisse mit deutlich geringeren Zugriffszeiten beim Schreiben, obwohl sich die Köpfe ja nicht schneller bewegen, wenn sie Schreiben statt Lesen sollen. Das umgeht man indem mehere Zugriffe gemacht werden und der Höchstwert genommen wird, der dann vermutlich eben nicht mehr in den Cache ging.

Wie ASS jetzt die Zugriffszeiten ermittelt weiß ich nichts, aber wenn es mit parallelen Zugriffen erfolgt, so kann alleine NCQ diesen Wert schon verfälchen ohne aber einen praktischen Nachteil zu bringen, ganz im Gegenteil: Durch das Umsortieren der Kommandos steigen die IOPS, einzelne Kommandos brauchen aber länger um bearbeitet zu werden. Solange die Zugriffszeiten also im Rahmen liegen, sollte man ihre Bedeutung bei SSDs nicht überbewerten da sie anders als bei den HDDs eben keine direkt Relation zu den IOPS haben.
 

Eggcake

Commodore
Dabei seit
Juni 2007
Beiträge
4.827
Die Zugriffszeit bedeutete schon bei der HDD, wie lange sie braucht um 512B Blöcke zu lesen (zufällig). Die Zugriffszeitmessungen beinhalteten immer das Positionieren inklusive dem Lesen des Blocks.

Dass kein NCQ verwendet wird, sieht man ganz einfach daran, dass die Werte (zumindest bei mir) unter IDE die genau gleichen sind. Und die (bei Benchmarks angezeigten) Zugriffszeiten stehen in direkter Relation zu den IOPS...es ist dasselbe, nur anders ausgedrückt. Bei der Zugriffszeitmessung könnte geradesogut ein IOPS oder MB/s-Wert stehen, mit der exakt gleichen Aussagekraft.

Stimmt aber, dass Zugriffszeitmessungen bei SSDs eigentlich keinen Sinn mehr machen. Bei HDDs konnte man daraus eigentlich direkt das Verhalten bei zufälligen Zugriffen ableiten (auch bei anderen Grössen), da der Hauptteil der Zugriffszeit eben für das Positionieren der Köpfe verwendet wurde. Bei SSDs kann man aus den Zugriffszeiten bei 512B jedoch überhaupt nichts ableiten - ausser eben die Performance bei 512B.
 
Zuletzt bearbeitet:
U

uNrEL2K

Gast
Zitat von Eggcake:
Die Zugriffszeit wirkt sich nur auf den Zugriff auf 512B aus, was relativ selten vorkommt. Anders gesagt:
20MB/s 4k Random und eine Zugriffszeit von 0.1ms sind genau gleich performant wie 20MB/s 4k Random und 1ms Zugriffszeit [bei 512B].

Genau erklären kann ich den Unterschied aber auch nicht - Auswirkungen auf die Performance hat das aber so gut wie keine.


0,1ms Read Zugriffszeit bedeutet, dass 512Byte Random Reads mit einer Transferrate
von ~5 MB/s übertragen werden können. Jede 0,1 Millisekunde 512 Byte.

Rechnung: 1 s = 1000 ms
1000 ms/0,1 ms = 10000 IOPS * 0,5 KB = 5000 KB/s / 1024 = 4,88... MB/s

Wenn, wie du sagst 512Byte Zugriffe eh selten vorkommen, und wir annehmen, dass 4K-Random Reads ist das häufigste Zugriffsmuster ist und wir mal 2 SSDs gegenüberstellen:


SSD A:
4K-Random - 20 MB/s
0,5K-Random (Zugriffszeit 0,1 ms) - 4,88 MB/s

SSD B:
4K-Random - 20 MB/s
0,5K-Random (Zugriffszeit 1,0 ms) - 0,488 MB/s

So ist die Zugriffszeit von SSD B (1 ms) zehnmal so hoch wie von SSD A (0,1 ms), aber diese Umstand hätte keinen Einfluss auf die, ich sage mal zum Beispiel Programmstart-Performance, wenn wir davon ausgehen, dass ein Programmstart hauptsächlich aus 4K-Random-Reads besteht. Denn im 4K Bereich sind hier beide SSDs gleich schnell.


Rein theoretisch dürfte der 4K Read Speed immer ungefähr achtfach so schnell sein wie die 0,5K Speed. Denn Ein SSD-Controller liest ja immer eine gesamte Page aus, welche oft 4K groß ist (bei 2x nm Flash 8K, aber den lass ich jetzt mal außen vor). Wenn also der Controller um 0,5K Benutzerdaten auszulesen die ganzen 4K der Page auslesen muss, hat er ungefähr das 8fache an "Arbeit", als er eigentlich bräuchte, um nur die Nutzdaten auszulesen.

bei meiner Postville G2 siehts so aus:

4K Read 23,01 MB/s
Acc.Time 0,146 ms (= ~ 3,34 MB/s)

23,01 / 3,34 = das 6,89fache bei 4K Read als bei 0,5K Read. Kommt also ungefähr hin was ich hier behaupte xD

Ganz interessant dazu fand ich einen heise-Artikel, der die Zeiten, die eine SSD braucht um eine Page auszulesen in die einzelnen Zwischenschritte aufgeschlüsselt.

 

rager

Lt. Commander
Dabei seit
Aug. 2004
Beiträge
1.770
Wenn es einen Thread gibt, wo die Funktionsweise von SSDs genaustens erklärt wirf, dann gehört uNrEL2K Rechnung da rein!
 

Holt

Banned
Dabei seit
Mai 2010
Beiträge
59.527
@uNrEL2K, die richtige Rechnung müßte die Zugriffszeit und die seq. Transferrate berücksichtigen um auf die Random IOPS bei QD1 besser als "6,89 entspreicht ungefähr 8, also stimmt das wohl" zu berechnen. Das geht aber wegen der parallelen Kanäle der SSDs nicht funktionieren, denn man liest ja 4k i.d.R. nur aus einem Chip und der hat, je nach Interface eben nur eine theoretische Bandbreite von 40, 133, 166 etc. MB/s und praktisch eben weniger, wie ct das ja auch erklärt (nur liegen bei MLC die Leseraten kaum unter denen von SLC, nur die Schreibraten).

Wenn Du die 4k Lesewerte heranziehst, so machst Du keine Berechnung sondern nur eine Umrechnung und auch die kommt nur fürs Lesen grob hin.
Schau Dir mal einige ASS Screenshots an:

as-ssd-benchocz-vertexpm07.png


as-ssd-benchc300-ctfddmsxi.png


Wieso hat die C300 trotz 2,7 facher Write AccessTime fast die 1,6fachen 4k Schreibwerte?
Vergiss also bitte die Zugriffszeiten von SSDs, diese spielen in der Praxis keine wirkliche Rolle und wenn man nicht weiß, ob die Durchschnitts- oder Spitzenwerte angezeigt werden, dann schon gleich garnicht. Die Spitzenwerte sind zuweilen recht groß, wenn beim Schreiben z.B. GC durchgeführt wird um die Daten neu anzuordnen. Die Ergebnisse in IOPS oder MB/s werden dann ja angezeigt und die kann man einfach umrechnen, MB/s / 4k (Testgröße) = IOPS, 40M/s bei 4k sind halt 10.000IOPS.
 
U

uNrEL2K

Gast
Zitat von Holt:
@uNrEL2K, die richtige Rechnung müßte die Zugriffszeit und die seq. Transferrate berücksichtigen um auf die Random IOPS bei QD1 besser als "6,89 entspreicht ungefähr 8, also stimmt das wohl" zu berechnen. Das geht aber wegen der parallelen Kanäle der SSDs nicht funktionieren, denn man liest ja 4k i.d.R. nur aus einem Chip und der hat, je nach Interface eben nur eine theoretische Bandbreite von 40, 133, 166 etc. MB/s und praktisch eben weniger, wie ct das ja auch erklärt (nur liegen bei MLC die Leseraten kaum unter denen von SLC, nur die Schreibraten).


1/8 der 4K-Read Performance sollte eigentlich ungefähr der 0,5K-Read Performance bzw. Zugriffszeit entsprechen.
genauso wie das 8fache der 0,5K-Read Performance bzw. Zugriffszeit der 4K-Read Performance entsprechen sollte.

Wieso die seq. Transferrate berücksichtigen? Die du weißt doch selbst, dass das aufgrund der Speicherkanäle nicht funktioniert. Vor allem ist sequenziller Zugriff eine andere Zugriffsart. Das kann man doch nicht vergleichen mit Random Zugriffen!?

Wenn Du die 4k Lesewerte heranziehst, so machst Du keine Berechnung sondern nur eine Umrechnung und auch die kommt nur fürs Lesen grob hin.

Wieso hat die C300 trotz 2,7 facher Write AccessTime fast die 1,6fachen 4k Schreibwerte?
Vergiss also bitte die Zugriffszeiten von SSDs, diese spielen in der Praxis keine wirkliche Rolle und wenn man nicht weiß, ob die Durchschnitts- oder Spitzenwerte angezeigt werden, dann schon gleich garnicht. Die Spitzenwerte sind zuweilen recht groß, wenn beim Schreiben z.B. GC durchgeführt wird um die Daten neu anzuordnen.

Schreiben habe ich absichtlich nicht erwähnt, einfach weil mein das mit Lesen nicht vergleichen kann. Die SSDs sind hier oft langsamer als beim Lesen, dann verhalten sich SLC & MLC verschieden. Da gibt es auch große Unterschiede zwischen den SSD Controllern. Siehe zB C300. 4K-Random-Write sich wohl nicht so einfachen umrechnen wie Read. Bei Read hingegen ist das aber ziemlich einheitlich.

Ob Intel X25-M, Vertex2 oder C300, da kannste die Zugriffszeit quasi direkt von der 4K-Ran-Read Performance ableiten oder umgekehrt. CPU, Taktzustände & Treiber spielen aber auch eine Rolle.

ASS sollte Durchschnittswerte angeben, sowie bei den anderen Werten auch.

PS:
Im ASS auf die IOPS Ansicht umzustellen ist natürlich noch einfacher als umrechnen ;)


MB/s Ansicht

as_02hd_02_mbs_marked-jpg.228722


Selber Durchlauf: IOPS Ansicht

Gleiche IOPS bei 512B (Zugriffszeit) und 4K-Ran-Read, macht

1/8 der 4K-Read Performance sollte eigentlich ungefähr der 0,5K-Read Performance bzw. Zugriffszeit entsprechen.
genauso wie das 8fache der 0,5K-Read Performance bzw. Zugriffszeit der 4K-Read Performance entsprechen sollte.


as_02hd_02_iops_marked-jpg.228723
 

Anhänge

  • as_02hd_02_MBs_marked.jpg
    as_02hd_02_MBs_marked.jpg
    89,8 KB · Aufrufe: 2.481
  • as_02hd_02_IOPS_marked.jpg
    as_02hd_02_IOPS_marked.jpg
    88,8 KB · Aufrufe: 2.392
Zuletzt bearbeitet:
O

Onkelhitman

Gast
Wikipedia:

"Heute enthalten MLC-Flashzellen jeweils 4 Bits und sind zu sogenannten Pages mit je 4096 Byte Größe zusammengefasst.[34] Angesprochen werden vom Controller immer ganze Pages. Beim Lesen einzeln, beim Schreiben werden sie abermals zusammengefasst – zu einem „Erasable Block“. Dieser enthält 64 oder 128 Pages und ist somit 256 oder 512 KB groß"

Das bedeutet doch, dass die Pages minimal 4KB haben und daher auch keine Dateien kleiner als 4KB geschrieben werden. Die kleinste Einheit wäre somit 4KB und da dieses von der SSD ja mit ca. 5300-5400 IOPS geschieht, so passiert dies bei den kleineren Dateien von 0,5KB (welche von der SSD damit ja in eine Page mit 4KB geschrieben wird) ebenfalls mit dieser Geschwindigkeit.
 
U

uNrEL2K

Gast
Wikipedia ist in dieser Hinsicht mal sowas von falsch, das müsste man eigentlich sofort ändern. MLC hat bei akutellen SSDs 2Bit pro Zelle. TLC (Triple Level Cell) mit 3Bit pro Zelle ist in Arbeit. Soweit ich weiß werden die aber nocht nicht beim Endkunden genutzt.
Beim Schreiben werden auch keine Pages zusammengefasst. Wie die Bezeichnung Erasable Block schon sagt, wird die Einteilung in eben diese Blöcke nur beim Löschen bzw. Überschreiben vorgenommen. Soll der Inhalt einer Page gelöscht werden, geht das nicht direkt, sondern nur über das Löschen eines ganzen Erasable Blocks, in dem sich die Page befindet. Das Selbe gilt beim Überschreiben einer Page, da eine Page, nicht wie bei einer Festplatte, direkt überschrieben werden kann, sondern zuvor gelöscht werden muss.

Die Quelle von Wikipedia Anandtech führt das Thema übrigens korrekt aus. Beim Übersetzen/Interpretieren des Textes scheint der Wiki-Autor Probleme gehabt zu haben.
Ergänzung ()

Zitat von Onkelhitman:
Das bedeutet doch, dass die Pages minimal 4KB haben und daher auch keine Dateien kleiner als 4KB geschrieben werden. Die kleinste Einheit wäre somit 4KB und da dieses von der SSD ja mit ca. 5300-5400 IOPS geschieht, so passiert dies bei den kleineren Dateien von 0,5KB (welche von der SSD damit ja in eine Page mit 4KB geschrieben wird) ebenfalls mit dieser Geschwindigkeit.

Beim Beim Schreiben ist das aber nicht/nicht immer, nur beim 4K-Ran-Read QD1.

Wie Holt schon richtig angemerkt hat, die Zugriffszeit der C300 beim ziemlich hoch
(0,7xx ms), das sind ungefähr 1300 IOPS). Bei 4K-Ran-Write QD1 hingegen sind es knapp 24.000 IOPS!
 
Zuletzt bearbeitet:
D

dank1985

Gast
Zitat von uNrEL2K:
Beim Beim Schreiben ist das aber nicht/nicht immer, nur beim 4K-Ran-Read QD1.

Wie Holt schon richtig angemerkt hat, die Zugriffszeit der C300 beim ziemlich hoch
(0,7xx ms), das sind ungefähr 1300 IOPS). Bei 4K-Ran-Write QD1 hingegen sind es knapp 24.000 IOPS!

Habe einfach mal einen Screenshot von meiner Crucial C300 64GB mit IOPS gemacht(SataII).
Bekannte Bugs in der Aktuellen version:

- NTFS Kompression auf dem Laufwerk führt zum falschen Ergebnis Quelle
 

Anhänge

  • iops c300 10.4.11.jpg
    iops c300 10.4.11.jpg
    162,9 KB · Aufrufe: 482
Zuletzt bearbeitet:
O

Onkelhitman

Gast
Wobei anzumerken ist, dass du die 64GB Version hast,die etwas langsamer ist als die 128GB.
 
Top