Serial ATA im Detail: Das sind die Vorteile gegenüber Ultra ATA

Command Queuing: TCQ versus NCQ (Fortsetzung)

Prinzipiell zeichnet sich Command Queuing durch drei entscheidende Features aus:

Erstens ein effizientes Statusrückgabeverfahren: Ein Protokoll zum Command Queuing muss festlegen, wie es dem Host-System sagen soll, dass ein Befehl abgearbeitet wurde. NCQ ermöglicht es dem Laufwerk, solche Bestätigungen für mehrere Befehle hintereinander oder sogar auf einmal an den Host zu versenden. Dies ist möglich, da das Protokoll keinen Handshake mit dem Host forciert. Ferner ist es für den Host auch dann noch klar erkennbar, welcher der Befehle zuerst abgearbeitet wurde, wenn die Vollendung zweier Befehle zeitlich nah aneinander liegt. Das Laufwerk kann insgesamt gleichzeitig die Status von 32 Befehlen in einem einzelnen 8 Byte großen Paket übermitteln.

Das TCQ-Protokoll benötigt hingegen bei jeder Befehlsabarbeitung einen Handshake zwischen Host und Laufwerk. Um überhaupt einen Befehl abarbeiten zu können, muss der Host gar einen zusätzlichen Befehl, genannt Service, an das Laufwerk versenden, um festzustellen, dass der Befehl vollendet wurde. Es gibt bei diesem Protokoll keinen Mechanismus, mit dem mehrere Bestätigungen simultan versendet werden können, woraus hohe Latenzen (Verzögerungen) entstehen.

Zweitens stellt bei jedem Datentransferprotokoll das Minimieren nötiger Interrupts seitens des Hosts einen Schlüssel zu höheren Leistungen dar. Jeder Interrupt erhöht sowohl CPU-Auslastung als auch die Latenzzeit. Diese Latenzzeit kann abhängig von der gesamten Systemauslastung von Mikro- bis hin zu Millisekunden variieren. NCQ wurde so entwickelt, dass höchstens ein Interrupt pro Befehl zum Einsatz kommt. Die tatsächliche Anzahl an Interrupts ist pro Befehl in der Regel sogar geringer als eins, wenn Interrupts entsprechend kombiniert werden. Dies ist seitens des Laufwerks explizit möglich, wenn es mehrere Befehle in derselben Zeit abarbeitet. Sollte dies nicht vom Laufwerk getan werden, kann das Ganze im Übrigen auch vom Host-Controller übernommen werden. Eine solche Situation kann bei hohen Systemauslastungen recht häufig auftreten, da das Ausführen der gewünschten Interrupts möglicherweise länger ist als die Zeit zwischen den einzelnen, ausgeführten Befehlen.

TCQ weist hier immerhin zwei Interrupts pro Befehl auf: Einen, um den Datentransfer einzuleiten und Einen, um den Befehl auszuführen. Auch besteht keine Möglichkeit, die Interrupts zusammenzufassen, da ja bekanntlich immer wieder ein Handshake von Nöten ist.

Drittens ist es auch ausschlaggebend, wenn sich das Laufwerk aussuchen darf, welcher Befehl als Nächster für einen Datentransfer verwendet werden soll. Das bedeutet im Endeffekt, dass das Gerät direkt auf den Speicherpuffer des Hosts zugreifen kann. Dieser Vorgang wird auch First Party DMA genannt, zu Deutsch quasi DMA aus erster Hand. NCQ unterstützt das Ganze, weswegen es den Geräten folglich möglich ist, direkt auf das Geschehen Einfluss zu haben, ohne vorher entsprechende Software konsultieren zu müssen. Die Auswahl des jeweiligen DMA-Kontextes wird mittels des Aussendens eines Paketes, das entsprechende Informationen zum gewünschten Befehl enthält, zum Host-Controller realisiert. Letzterer regelt dann den Rest, woraufhin die DMA-Übertragung dann auch schon stattfinden kann.

Ein solches Vorgehen wird vom TCQ-Protokoll nicht unterstützt. Dieses verursacht hingegen einen Interrupt, wenn es bereit ist, Daten zu übertragen. Dieser Interrupt wird dann vom Host verarbeitet. Anschließend muss Letzterer dann noch einen Befehl an das Laufwerk aussenden, um zu erfahren, welcher Befehl für den Datentransfer benötigt wird. Eine solche Methode zieht die Latenzzeiten in die Höhe und wirkt sich letztendlich negativ auf die Leistung aus.