Zum Hauptinhalt Zur Navigation

Festplatten: Das macht NVMe anders (und besser) als Sata

Golem-Erklärbär
Wir erklären, wie Prozessor und Speichermedien Daten austauschen, was NVMe anders macht als Sata und warum es für SSDs besser geeignet ist.
/ Johannes Hiltscher
96 Kommentare News folgen (öffnet im neuen Fenster)
NVMe und Sata erfüllen beide denselben Zweck - und sind doch sehr verschieden. (Bild: Johannes Hiltscher, Golem.de)
NVMe und Sata erfüllen beide denselben Zweck - und sind doch sehr verschieden. Bild: Johannes Hiltscher, Golem.de

Grundsätzlich ist die Aufgabe eines Protokolls zur Kommunikation mit Festplatten einfach: Es muss mitteilen, von wo auf dem Speichermedium Daten gelesen und wo sie im RAM des Systems abgelegt werden sollen. Beim Schreiben wird nur die Richtung umgedreht, daneben müssen noch ein paar Befehle und Statusinformationen übermittelt werden. Diese einfache Funktion lässt sich aber auf ganz unterschiedliche Weisen realisieren. Wir sehen uns an, wie das beim alten Standard Sata (für Serial Advanced Technology Attachment) mit dem neueren NVMe (für Non-Volatile Memory express) funktioniert.

Da verschiedene Speichermedien unterschiedlich angesteuert werden, ist immer ein Controller erforderlich. Er setzt ein für den Prozessor angenehmes Protokoll in Ansteuerinformationen für das Speichermedium um. Bei klassischen HDDs und optischen Laufwerken müssen die Schreib-Lese-Köpfe positioniert, bei SSDs die passenden Flash-Chips angesprochen werden. Hier finden wir auch gleich den ersten Unterschied.

Beim klassischen Sata, dessen Geschichte bis ins Jahr 1989 zurückgeht, findet sich neben dem Controller der Festplatte noch ein sogenannter Host-Controller. Er übersetzt von einer Host-Schnittstelle, oft PCI(e), zunächst auf ein standardisiertes Protokoll zur Kommunikation mit einem oder mehreren Speichermedien über eine ebenfalls standardisierte Schnittstelle.

Nur noch ein Controller

Bei NVMe fällt der Host-Controller weg, jede SSD integriert stattdessen ein komplexeren Controller, der auch Aufgaben übernimmt, die bei Sata der Host-Controller erledigt. Dazu gehört der direkte Speicherzugriff mittels DMA (Direct Memory Access). Damit werden Daten in den RAM geschrieben oder von dort gelesen und so mit Anwendungen ausgetauscht.

Auf den ersten Blick mag es sinnvoll erscheinen, wie bei Sata sowie dessen Vorgänger mit parallelem Datenbus (PATA) nur einen komplexen Host- und viele einfache Festplatten-Controller zu verwenden. Die Vermittlung durch den Host-Controller macht allerdings ein recht komplexes Protokoll erforderlich, über das er mit dem Festplatten-Controller kommuniziert. Dabei muss der Host-Controller einige der vom Gerät erzeugten Datenstrukturen (Frame Information Structures, FISs) selbst verarbeiten, etwa um mittels DMA gelesene Daten in den RAM zu schreiben.

Andere FISs muss er hingegen in einen Puffer im Speicher schreiben, damit der Treiber sie auswerten kann. Für SSDs, die im Vergleich zu den klassischen HDDs wesentlich geringere Zugriffslatenzen haben, ist das allerdings Gift. Denn jede Kommunikation zwischen den beteiligten Controllern bedeutet eine Verlängerung der Latenz beim Zugriff auf den RAM.

Das Protokoll wird radikal einfacher

Die lange Geschichte von Sata geht mit einem immer weiter gewachsenen Protokoll mit über 100 ATA-Befehlen einher, dazu kommen noch die ATAPI-Befehle, die etwa für optische Laufwerke erforderlich sind. Die meisten der vielen Befehle sind für SSDs irrelevant. NVMe markiert hier einen kompletten Neuanfang mit dem Ziel, einen möglichst kompakten Befehlssatz zu schaffen. Der führt zu einfacheren Datenstrukturen und lässt sich zudem effizienter übertragen.

Während bei Sata mehrere Zugriffe auf Register des Host-Controllers erforderlich sind, um ein Kommando zum Festplatten-Controller zu schicken, genügt bei NVMe laut Spezifikation (PDF)(öffnet im neuen Fenster) einer. Die Register, die etwa das von Intel entwickelte Advanced Host Controller Interface (AHCI, PDF)(öffnet im neuen Fenster) definiert, können zudem nicht gecached werden. Der Grund dafür ist, dass sie sowohl vom Prozessor als auch vom Host-Controller beschrieben werden. Das führt dazu, dass jeder Zugriff eine kleine und mit paketbasierten Schnittstellen wie PCIe (g+) ineffiziente Transaktion auslöst.

Die Schnittstelle zum Senden von Kommandos zur SSD (und zum Empfangen ihrer Antworten) ist bei NVMe ebenfalls deutlich einfacher.

Zirkuläre Puffer und eine Klingel

Bei NVMe werden Kommandos und Antworten mittels einfacher zirkulärer Puffer ausgetauscht. Sie heißen schlicht Command und Completion Queue; die Command Queue ist eine Warteschlange mit abzuarbeitenden Befehlen. Zirkuläre Puffer sind Speicherbereiche fester Größe, zu denen jeweils ein Schreib- und ein Leseindex gehören. Hat einer davon das Ende der Liste erreicht, wird er zurück auf 0 gesetzt.

Der Vorteil: Die Indizes und Listen werden jeweils exklusiv vom Prozessor oder dem Controller des damit angesprochenen Geräts beschrieben. Damit entfällt etwa das Lesen eines Statusregisters, das bei Sata erforderlich ist, bevor ein neues Kommando übergeben werden kann. Der Treiber kann Kommandos in die Warteschlange einfügen, im Extremfall, bis sie voll ist. Anschließend setzt er den Schreibindex, der in einem Register des NVMe-Controllers liegt.

Durch das Schreiben des Registers erkennt der Controller, dass neue Befehle vorliegen und beginnt sie abzuarbeiten. Der Mechanismus wird als Doorbell(öffnet im neuen Fenster) , also Klingel, bezeichnet und funktioniert ähnlich wie ein Interrupt.

Den wiederum kann der Controller nutzen, um den Treiber über abgearbeitete Kommandos zu informieren. Dazu schreibt er diese zuerst in die Completion Queue, setzt dann deren Schreibzeiger und löst einen Interrupt aus. Anhand der Completion Queue passt der Treiber dann den Leseindex der Command Queue an.

Warteschlangen sind für SSDs extrem wichtig

Um einen Datenträger möglichst effizient beschäftigt zu halten, ist eine Befehlswarteschlange unumgänglich. Daher wird sie mindestens seit dem AHCI von Host-Controllern verwendet. Allerdings kennt hier erst einmal nur der Host-Controller die Warteschlange, was noch immer dazu führt, dass der Festplatten-Controller auf den nächsten Befehl warten muss, nachdem er einen abgearbeitet hat.

Dieses Problem löste Sata-II 2004 mit einer Technik namens Native Command Queueing (NCQ, ein White Paper von Intel gibt einen guten Überblick [PDF](öffnet im neuen Fenster) ). Damit lassen sich mehrere Befehle direkt an den Festplatten-Controller schicken, der sie dann in beliebiger Reihenfolge abarbeitet. Der Kerngedanke dabei war, dass mechanische Festplatten Lese- und Schreibbefehle umsortieren können sollten, um sie bestmöglich mit der Bewegung der Platten und der Lese-Schreib-Köpfe abzustimmen.

Für SSDs ist das besonders wichtig, da sie, anders als mechanische Festplatten (mit Ausnahme von Modellen mit unabhängigen Schreib-Lese-Köpfen ), mehrere Befehle parallel abarbeiten können. Der Flash-Speicher ist über mehrere Kanäle angebunden, die unabhängig bedient werden. Genau hier kommt NCQ an seine Grenzen: Es gibt nur eine Warteschlange, und die ist mit lediglich 32 ausstehenden Kommandos auch noch sehr klein. Sie zu erweitern, wäre kompliziert, da AHCI für die Verwaltung der Einträge ein 32-Bit-Register verwendet. Die SSD hat damit wenig Auswahl, um alle Kanäle beschäftigt zu halten; klappt es doch, ist die Queue schnell leer, was Leerlauf aufgrund der erforderlichen Kommunikation mit dem Treiber bedeutet.

Viel mehr und viel größere Warteschlangen

Die Beschränkung auf eine Queue hat noch ganz andere Nachteile: Sie stammt noch aus einer Zeit, in der Prozessoren nur einen Kern hatten. Wollen Prozesse auf mehreren Kernen auf die eine Queue zugreifen, müssen sie sich synchronisieren, was Zeitaufwand bedeutet.

NVMe greift deshalb in die Vollen: 65.535 Warteschlangen sind möglich, eine ist für Verwaltungsaufgaben vorgesehen. So kann quasi jeder Thread eine eigene Warteschlange nutzen, sie können zudem noch mit Prioritäten versehen werden. Nicht nur gibt es wesentlich mehr Queues, jede kann zudem 65.535 Befehle aufnehmen. So können Prozessor und Speichermedium lange Zeit ungestört arbeiten, ohne sich abstimmen zu müssen.

Wer NVMe hört, denkt sehr wahrscheinlich PCIe gleich mit. Und das aus gutem Grund, denn ohne Letzteres ist Ersteres kaum vorstellbar.

NVMe ohne PCIe: Kaum denkbar

Wer sich die Spezifikation von NVMe ansieht, merkt schnell: Sie ist PCIe quasi aufs Protokoll geschneidert. Statt mit Hilfe vieler Register werden alle Kommandos als 64-Byte-Paket übertragen, in dem alle benötigten Parameter enthalten sind. Das macht die Datenübertragung effizient. Auch von den sogenannten Message Signaled Interrupts (MSI) macht NVMe großzügig Gebrauch, so können Completion Queues jeweils individuelle Interrupts zugeordnet werden.

Zwar ist auch die Möglichkeit, die Kommandos über ein anderes Protokoll zu tunneln, vorgesehen, was durch das rein paketbasierte Format recht einfach ist. Das nennt sich NVMe over Fabrics, geht allerdings mit einigen Einschränkungen einher, besonders bei der Verwaltung der Command Queues. Sie erreichen ihre maximale Flexibilität nur, wenn der Controller auf der SSD direkt auf den RAM, in den Daten sollen oder aus dem sie kommen, zugreifen kann.

Nur PCIe schafft die Datenraten moderner SSDs

Dass eine Weiterentwicklung von Sata abseits des Protokolls wenig sinnvoll ist, hat auch die Sata International Organization (Sata-IO) erkannt. Sie verwaltet die verschiedenen Spezifikationen des Standards und setzt seit 2013 ebenfalls auf PCIe , anstatt die eigene physische Schnittstelle weiterzuentwickeln.

Mit dessen hoher Datenrate pro Link und der Möglichkeit, Links zur weiteren Steigerung der Bandbreite zu bündeln, kann Sata ohne eine komplette Überarbeitung der Schnittstelle nicht einmal gleichziehen. Für SSDs hat Sata eigentlich seit Jahren ausgedient, da ihre Bandbreite schneller wuchs, als die Schnittstelle mithalten konnte.

Für die gern zum Ablegen großer Datenmengen genutzten großen, mechanischen Festplatten, umgangssprachlich Datengräber genannt, wird uns Sata noch einige Zeit erhalten bleiben - schließlich wurde es genau dafür entwickelt. Da diese Technologie, abgesehen von weiteren Kapazitätssteigerungen, ziemlich ausgereizt ist, sind die Bandbreiten mechanischer Festplatten im vergangenen Jahrzehnt kaum gewachsen. Die Consumer-Modelle sind mit Sata ausreichend schnell angebunden, lediglich sehr teure Server-Festplatten bringen die Schnittstelle an ihr Limit.

Daher gab es etwa bei Seagate die Überlegung, selbst mechanische Festplatten mittels NVMe anzubinden . Auch wenn NVMe das seit Version 2.0 unterstützt, liefert Seagate aber selbst die aktuell leistungsfähigsten mechanischen Festplatten mit über 500 MByte/s Lese- und Schreibgeschwindigkeit noch immer nur mit Sata- und Sas-Schnittstelle aus. Selbst im oberen Leistungsbereich ist Sata also noch lange nicht überholt.


Relevante Themen