Werbung
Die meisten SSD-Hersteller geben die Performance der SSDs mit zwei Kennzahlen an: Die IOPS und die Transferrate haben sich als Maßzahl für die Geschwindigkeit einer SSD etabliert. In einer recht mathematischen technischen Session zeigte Intel, warum diese Kennzahlen nicht unbedingt für alle Anwendungsbereiche sinnvoll sein können - und warum eine SSD mit hohen IOPS unter umständen nicht schneller als eine SSD mit niedrigen IOPS sein muss.
Ausgangspunkt der Überlegungen ist das Schreibverhalten auf NAND-Chips: Fallen beispielsweise sechs Schreibzyklen bei einer SSD an, die sechs NAND-Chips besitzt, ist die statistische Wahrscheinlichkeit so verteilt, dass durchschnittlich zwei NAND-Chips zwei Schreibzyklen ausführen müssen, zwei NAND-Chips genau einen Schreibzyklus ausführen und zwei NAND-Chips gar nicht verwendet werden. Entsprechend dauert das gesamte Schreiben auf der SSD doppelt so lange, als wenn die Daten genau gleichmäßig auf allen NAND-Chips verteilt werden könnten. Diesen Effekt bezeichnete der Intel-Entwickler als "Yahtzee-Effekt" nach dem entsprechenden Würfelspiel. Hier ist die Wahrscheinlichkeit bei sechs Würfeln identisch verteilt: Es gibt mathematisch am häufigsten zwei Paare.
Die Performance einer SSD ist dabei als eine Art mathematischer Funktion zu verstehen: Die Hardware gibt die IOPS vor, die entsprechende Software und die Anwendungen führen dabei zu einer unterschiedlichen Queue-Depth.
Geht man nun von einer größeren Anzahl von NAND-Dies aus, so steigt entsprechend dieser Effekt an. Intel zeigte die weiteren Überlegungen mit 50 NAND Dies, die ca. 10K IOPS pro Die erreichen können. Bei einer optimalen Verteilung der Schreibzyklen würden bis zu einer Queue-Tiefe von 50 die IOPS linear ansteigen, bis genau 50x 10K IOPS erreicht sind. Anschließend würden weitere Schreibzyklen ebenso effizient aufgeteilt werden, die Gesamtleistung würde bei 500K IOPS verbleiben.
Aufgrund des Yahtzee-Effekts ist dies leider nicht so: Die tatsächliche IOPS-Leistung der SSD bleibt hinter der theoretischen Leistung zurück. Der Peak bei einer hohen Queue-Depth (256) ist zwar nahe an den 500K IOPS, gerade im Bereich der typischen Anwendungsbereiche zwischen 0 und 64 gleichzeitigen Zugriffen liegt die SSD aber in einem vergleichsweise ineffizienten Bereich unterhalb der theoretischen IOPS.
Da SSDs eine unterschiedliche Charakteristik haben, wie die Verteilung der Schreibzyklen stattfindet, aber auch die maximalen IOPS sich unterscheiden, kann es sein, dass eine SSD, die eine hohe tatsächliche IOPS-Anzahl ausweist, im kritischen Bereich langsamer ist als eine SSD mit einer vergleichsweise niedrigen IOPS-Peak-Leistung.
Allerdings ist es nicht nur sinnvoll, die Schreibleistung bei verschiedenen Queue-Tiefen anzusehen, sondern auch die Latenzzeit ist bei unterschiedlicher Queue-Tiefe ausschlaggebend. Je höher dabei die Queue-Depth, desto größer ist die durchschnittliche Latenzzeit. Ein Drittel der IOPS brauchen demnach nur halb so lange zum Schreiben. Der Grund liegt in der Wahrscheinlichkeit, dass ein "freier" Die gefunden wird und nicht gewartet werden muss. Kollisions-Effekte führen hingegen zu langsamen Zugriffen.
Oftmals wird bei Leistungsvergleichen die IOPS-Gleichmäßigkeit als Kennzahl dafür verwendet, wie gut die Leistung einer SSD aus QoS-(Quality of Service)-Sicht ist. Eine SSD, die beispielsweise durchgängig 200.000 IOPS (Operationen in einer Sekunde) liefert, ohne Aussetzer nach unten zu haben, wird als leistungsfähiger angesehen als eine SSD, die 175.000 IOPS leistet. Das muss aber für den QoS-Bereich nicht immer gelten: Kann die SSD besonders schwierige Schreibvorgänge nach hinten stellen, kommt eine besonders hohe IOPS-Leistung zustande, einzelne Schreibzugänge besitzen aber eine extrem hohe Service Time. Selbst wenn 99,99% der Schreibvorgänge zügig durchgeführt werden, können die verbleibenen mehrere Millisekunden dauern und deshalb zu einer schlechten Anwendungserfahrung führen.
Um diese Latenzzeit applikationsabhängig darzustellen, muss ein Anwendungsentwickler wissen, wie zeitkritisch bestimmte Vorgänge sind. Ist es beispielsweise bei einer Börsenapplikation notwendig, die Daten mit einer Verzögerung von 5ms zu liefern, kann man bei der Betrachtung der Latenz genau dies als maximale QoS-Zeit annehmen. Eine SSD muss demnach schneller sein als dieser Wert, beispielsweise bei 99,99% der IOPS. In der unten stehenden Grafik ist bei diesen 99,99% die IOPS-Leistung von zwei SSDs dargestellt. Bei 5ms ist die SSD mit der blauen Funktion fast drei Mal so schnell wie die grüne SSD.
Ein weiterer interessanter Effekt bei SSDs betrifft gleichzeitige Schreib- und Lesezugriffe. Geht man als Beispiel von einem Mix von 70% Lesen und 30% Schreiben aus, könnte man vermuten, dass entsprechend der Prozentzahlen die Lese- und Schreibleistung ausfällt: Kann eine SSD bei einer Queue-Tiefe von 40 beispielsweise 300K IOPS Lesen und 150.000K schreiben, so könnte man vermuten, dass sich die Gesamtleistung folgendermaßen zusammensetzt:
0,7x 300K + 0,3x 150K = 255K
Leider ist dies aufgrund des sogenannten Read/Write Mixing Effects nicht korrekt. Die Gesamtleistung ist deutlich niedriger, weil die Queue-Tiefe einzeln betrachtet werden muss. Richtig ist es, die Performance dann mit der entsprechenden Queue-Tiefe zu betrachten. Die Leistung ist also beim Schreiben nur mit der langsameren Queue-Tiefe von 40*0,3 zu betrachten und beim Schreiben mit 40*0,7. Durch den Yahtzee-Effekt ist die Gesamtleistung deutlich niedriger als die oben genannte Rechnung.
Zuletzt sprach Intel auch über weitere Entwicklungen im AHCI Stack, den man deutlich effizienter gestalten muss, um die hohen IOPS verarbeiten zu können. Der aktuelle AHCI-Stack ist hierfür nicht ausgelegt, da er noch auf Harddisks ausgelegt ist. SSDs - und vor allen Dingen die kommenden NVM PCI-Express-SSDs besitzen deutlich höhere IOPS und führen somit zu einer beachtlichen CPU-Last. Die CPU-Leistung möchte Intel aber natürlich nicht für Storage-Management-Funktionen vergeuden, sondern für tatsächliche Berechnungen. Ein effizienter AHCI-Stack würde zudem auch die Latenz verringern. Entsprechend hat man bereits einen neuen Linux-Stack entwickelt, der diese Probleme beseitigen soll und um den Faktor 3 effizienter sein soll.
