NVMe vs. AHCI – und warum NVMe ein riesen Schritt vorwärts ist
Beim Kauf unseres neuesten Servers (siehe hier) waren wir von vorneherein auf eine der Intel Data Center P3XXX SSDs als PCIe Steckkarte fixiert.
Kurzzeitig kam dann die Frage auf, ob wir nicht lieber die “NVMe-Variante” in bewährter 2.5 Zoll Bauweise haben wollen.
Eine kurze Recherche über NVMe, und was es eigentlich ist, hat diese Frage dann geklärt: NVMe ja, aber bitte trotzdem als PCIe Steckkarte – NVMe verwenden diese nämlich ganz genau so, nur dass sie nicht über den SATA-Express U.2 (früher SF-8639) Stecker angekabelt werden.
Was ist NVMe?
Es ist so: Eine Protokollschicht über den tatsächlichen Bus-Verbindungen zwischen SSD und Motherboard (sprich: SATA / PCIe / …) kommt eine logische Schnittstelle, die den Zugriff auf die Massenspeichergeräte (seien es Festplatten, SSDs oder Optische / andere Bandlaufwerke) regelt – so muss nicht jeder Hersteller eines Massenspeicher-Gerätes einen eigenen Treiber für jedes Gerät schreiben.
Auf dieser Protokollschicht ist – noch – AHCI (Advanced Host Controller Interface) der de-facto Standard. AHCI ist zwar Teil des SATA-Standards, befindet sich auf logischer Ebene aber eine Abstraktionsstufe höher.
NVMe vs. AHCI
Nun wurde AHCI in Zeiten entworfen, als Flash-Speicher noch teuer, kurzlebig und unzuverlässig war, und keiner daran dachte, diesen ernsthaft als Ersatz für Festplatten einzusetzen.
Das führt dazu, dass – besonders in Kombination mit den heutigen, hochparallelen CPUs, oft auch die AHCI-Schnittstelle das Nadelöhr ist, wenn schnelle SSDs – wie im Business-Bereich üblich – zum Einsatz kommen.
Ein kurzer Vergleich – gefunden auf Wikipedia EN: NVM_Express / Comparison with AHCI:
| AHCI | NVMe | |
|---|---|---|
| Max. Größe der Command-Queue | 1 queue; 32 commands / queue | 65.536 queues; 65.536 commands / queue |
| Nicht cachebare Registerzugrife | 6 / non-queued command 9 / queues command |
2 / command |
| MSI-X und Interrupt-Steuerung | 1 Interrupt, keine Steuerung | 2.048 MSI-X interrupts |
| Parallelisierung + Multi-Threading | benötigt Synchronisationspunkt (lock) zum senden eines Commands | keine Synchronisationspunkte nötig |
| Effizienz für 4 KByte commands | command-Parameter brauchen zwei serialisierte host DRAM fetches | alle command-Parameter in einem 64-Byte fetch |
Warum NVMe so ein riesen Schritt vorwärts ist
Als Ersatz für AHCI ist NVMe schon ein guter Schritt – und wird mit steigender SSD-Performance sicher auch dort in ein paar Jahren eine Rolle spielen.
Ein wahrer Segen ist NVMe aber für die Hersteller und Anwender von PCIe-SSDs: Hier gab es nämlich bisher überhaupt keinen Standard, über welches Protokoll sich das Betriebssystem mit der SSD unterhält – was dazu führte, dass jeder Hersteller für jede PCIe-SSD und jedes Betriebssystem einen eigenen Treiber herausbringen musste.
Die Hersteller sparen sich jetzt also Arbeit in der Produktentwicklung.
Und die Kunden? Ohne hier Erfahrungen vorweisen zu können, behaupte ich, dass bei der kleinen Losgröße, in der die PCIe-SSDs bisher gebaut wurden, der Treibersupport mit Sicherheit nicht in allen Fällen optimal gewesen ist: Von gänzlich fehlenden Treibern für bestimmte Gerät-Betriebssystem-Kombinationen, über Fehlerhafte Treiber, bis hin zu hochgradig uneffizienten Treibern, für die der Hersteller aus Kostengründen einfach kein Update mehr liefert, gab es bestimmt das eine oder andere Treiberproblem.
Wir als Kunden von Business-SSDs begrüßen den Schritt hin zu NVMe daher sehr, und freuen uns schon auf unser nächstes Gerät mit einer der tollen PCI-Express-Karten!
