Motivation

Bei einer Signalrate von 480 MBit/s sollen USB 2.0-Geräte Daten mit bis zu 60 MB/s übertragen können. Allerdings scheinen die heutigen Geräte beim Lesen [ Wiki:USB ] auf 30-42 MB/s begrenzt zu sein. Das ist ein Overhead von 30 Prozent.

USB 2.0 ist seit über 10 Jahren ein De-facto-Standard für externe Geräte. Eine der wichtigsten Anwendungen für die USB-Schnittstelle war schon früh die tragbare Speicherung. Leider war USB 2.0 schnell ein geschwindigkeitsbegrenzender Engpass für diese bandbreitenintensiven Anwendungen, eine heutige Festplatte ist beispielsweise in der Lage, mehr als 90 MB/s beim sequentiellen Lesen zu erreichen. Angesichts der langen Marktpräsenz und des ständigen Bedarfs an höherer Bandbreite ist zu erwarten, dass das USB 2.0-Ökosystem über die Jahre optimiert wurde und eine Leseleistung nahe am theoretischen Limit erreicht hat.

Was ist die theoretische maximale Bandbreite in unserem Fall? Jedes Protokoll hat Overhead, einschließlich USB, und gemäß dem offiziellen USB-2.0-Standard sind es 53,248 MB/s [ 2 , Tabelle 5-10]. Das bedeutet, dass heutige USB-2.0-Geräte theoretisch um 25 Prozent schneller sein könnten.

Analyse

Um diesem Problem auch nur annähernd auf den Grund zu gehen, zeigt die folgende Analyse, was auf dem Bus passiert, während sequentielle Daten von einem Speichergerät gelesen werden. Das Protokoll wird Schicht für Schicht zerlegt und uns interessiert besonders die Frage, warum 53.248 MB/s die maximale theoretische Zahl für Massen-Upstream-Geräte ist. Abschließend sprechen wir über die Grenzen der Analyse, die uns einige Hinweise auf zusätzlichen Overhead geben könnten.

Anmerkungen

In dieser Frage werden nur Dezimalpräfixe verwendet.

Ein USB 2.0-Host kann mehrere Geräte (über Hubs) und mehrere Endpunkte pro Gerät handhaben. Endpunkte können in verschiedenen Übertragungsmodi betrieben werden. Wir werden unsere Analyse auf ein einzelnes Gerät beschränken, das direkt an den Host angeschlossen ist und in der Lage ist, im Hochgeschwindigkeitsmodus kontinuierlich vollständige Pakete über einen Upstream-Massenendpunkt zu senden.

Rahmung

Die USB-Hochgeschwindigkeitskommunikation wird in einer festen Rahmenstruktur synchronisiert. Jeder Frame ist 125 us lang und beginnt mit einem Start-Of-Frame-Paket (SOF) und wird durch eine End-Of-Frame-Sequenz (EOF) begrenzt. Jedes Paket beginnt mit SYNC und endet mit einem End-Of-Packet (EOF). Diese Sequenzen wurden den Diagrammen zur Verdeutlichung hinzugefügt. EOP ist in der Größe variabel und paketdatenabhängig, bei SOF sind es immer 5 Bytes.

Öffnen Sie das Bild in einem neuen Tab, um eine größere Version anzuzeigen.

Transaktionen

USB ist ein vom Master gesteuertes Protokoll und jede Transaktion wird vom Host initiiert. Der Zeitschlitz zwischen SOF und EOF kann für USB-Transaktionen verwendet werden. Das Timing für SOF und EOF ist jedoch sehr streng und der Host initiiert nur Transaktionen, die innerhalb des freien Zeitfensters vollständig abgeschlossen werden können.

Die Transaktion, an der wir interessiert sind, ist eine erfolgreiche Bulk-IN-Transaktion. Die Transaktion beginnt mit einem Token-Paket IN, dann wartet der Host auf ein Datenpaket DATA0/DATA1 und bestätigt die Übertragung mit einem Handshake-Paket ACK. Die EOP für alle diese Pakete beträgt 1 bis 8 Bit, abhängig von den Paketdaten, wir haben hier den schlimmsten Fall angenommen.

Zwischen diesen drei Paketen müssen wir jeweils mit Wartezeiten rechnen. Diese befinden sich zwischen dem letzten Bit des IN-Pakets vom Host und dem ersten Bit des DATA0-Pakets des Geräts und zwischen dem letzten Bit des DATA0-Pakets und dem ersten Bit des ACK-Pakets. Wir müssen keine weiteren Verzögerungen berücksichtigen, da der Host direkt nach dem Senden eines ACK mit dem Senden des nächsten IN beginnen kann. Die Kabellaufzeit ist mit maximal 18 ns definiert.

Eine Massenübertragung kann bis zu 512 Bytes pro IN-Transaktion senden. Und der Host wird versuchen, so viele Transaktionen wie möglich zwischen den Frame-Begrenzern auszugeben. Obwohl die Massenübertragung eine niedrige Priorität hat, kann sie die gesamte verfügbare Zeit in einem Slot beanspruchen, wenn keine andere Transaktion anhängig ist.

Um eine ordnungsgemäße Taktwiederherstellung sicherzustellen, definieren die Standards eine Methode, die Bitstuffing aufruft. Wenn das Paket eine sehr lange Folge derselben Ausgabe erfordern würde, wird eine zusätzliche Flanke hinzugefügt. Das sorgt für eine Flanke nach maximal 6 Bit. Im schlimmsten Fall würde dies die Gesamtpaketgröße um 7/6 erhöhen. Das EOP unterliegt keinem Bit-Stuffing.

Öffnen Sie das Bild in einem neuen Tab, um eine größere Version anzuzeigen.

Bandbreitenberechnungen

Eine Bulk-IN-Transaktion hat einen Overhead von 24 Bytes und eine Nutzlast von 512 Bytes. Das sind insgesamt 536 Bytes. Der Zeitschlitz dazwischen ist 7487 Bytes breit. Ohne Bitstuffing ist Platz für 13.968 Pakete. Bei 8000 Micro-Frames pro Sekunde können wir Daten mit 13 * 512 * 8000 B/s = 53,248 MB/s lesen

Für völlig zufällige Daten erwarten wir, dass Bitstopfen in einer von 2**6 = 64 Folgen von 6 aufeinanderfolgenden Bits erforderlich ist. Das ist eine Steigerung von (63 * 6 + 7) / (64 * 6). Die Multiplikation aller Bytes, die dem Bit-Stuffing unterliegen, mit diesen Zahlen ergibt eine Gesamttransaktionslänge von (19 + 512) * (63 * 6 + 7) / (64 * 6) + 5 = 537,38 Bytes. Das ergibt 13.932 Pakete pro Micro-Frame.

Bei diesen Berechnungen fehlt ein weiterer Spezialfall. Der Standard definiert eine maximale Geräteantwortzeit von 192 Bitzeiten [ 2 , Kapitel 7.1.19.2]. Dies muss bei der Entscheidung berücksichtigt werden, ob das letzte Paket noch in den Rahmen passt, falls das Gerät die volle Reaktionszeit benötigt. Wir könnten dies berücksichtigen, indem wir ein Fenster von 7439 Bytes verwenden. Die resultierende Bandbreite ist jedoch identisch.

Was ist übrig

• Fehlererkennung und Wiederherstellung wurde nicht behandelt. Möglicherweise treten Fehler häufig genug auf oder die Fehlerbehebung ist zeitaufwändig genug, um sich auf die durchschnittliche Leistung auszuwirken.

• Wir haben eine sofortige Host- und Gerätereaktion nach Paketen und Transaktionen angenommen. Ich persönlich sehe keine Notwendigkeit für große Verarbeitungsaufgaben am Ende von Paketen oder Transaktionen auf beiden Seiten und kann mir daher keinen Grund vorstellen, warum der Host oder das Gerät nicht in der Lage sein sollte, mit ausreichend optimierten Hardwareimplementierungen sofort zu reagieren. Insbesondere im Normalbetrieb könnten die meisten Buchhaltungs- und Fehlererkennungsarbeiten während der Transaktion durchgeführt werden, und die nächsten Pakete und Transaktionen könnten in die Warteschlange gestellt werden.

• Übertragungen für andere Endpunkte oder zusätzliche Kommunikation wurden nicht berücksichtigt. Möglicherweise erfordert das Standardprotokoll für Speichergeräte eine kontinuierliche Seitenkanalkommunikation, die wertvolle Slot-Zeit verbraucht.

• Es kann einen zusätzlichen Protokoll-Overhead für Speichergeräte für die Gerätetreiber- oder Dateisystemebene geben. (Paketnutzlast == Speicherdaten?)

Frage

• Warum sind heutige Implementierungen nicht in der Lage, mit 53 MB/s zu streamen?

• Wo liegt der Engpass bei heutigen Implementierungen?

Und ein mögliches Follow-up: Warum hat niemand versucht, einen solchen Engpass zu beseitigen?

Verweise

[1] Die offizielle USB 2.0-Spezifikation

[2] Schneller PDF-Spiegel der Spezifikation