mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik USB Bulk Transfer Ablauf optimieren


Autor: USBman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe eine einfache USB-Konfiguration aus Host und Client (ein FTDI), 
wobei der Client große Datenmengen an den Host per "Bulk Transfer" 
überträgt. Der Bus ist also ansonsten frei und unbelastet.

Ich möchte gerne die Paketgröße optimieren, da ich sie selbst bestimmen 
kann. Laut http://www.beyondlogic.org/usbnutshell/usb4.shtml#Bulk werden 
bei USB 2.0 Full Speed in einem Bulk Transfer entweder 8, 16, 32 oder 
maximal 64 Bytes übertragen.

Und daß eine Datenübertragung fertig ist, scheint wohl signalisiert zu 
werden, indem entweder ein Bulk Transfer mit weniger als 64 Bytes 
gesendet wird, oder falls der Datenblock durch 64 teilbar war ein leerer 
Bulk Transfer.

Außerdem scheint mir, daß die ersten beiden Bytes eines Blocks 
reserviert sind (Wofür?), so daß maximal 62 Bytes übertragen werden 
können.

Meine Überlegung ist nun: Am besten teile ich meine gesamten Daten in 
Pakete zu maximal 30 Bytes auf, denn dann wird jeweils genau ein Bulk 
Transfer durchgeführt und kein zusätzlicher Bulk Transfer ist nötig als 
Endemarkierung.

Oder ich nehme n*62+30, damit eben der letzte Bulk Transfer weniger als 
64 Bytes hat, aber so viele wie möglich.


Sind meine Überlegungen so richtig oder habe ich etwas entscheidendes 
übersehen?

Werden die einzelnen 64-Byte-Bulk-Transfers ohne Lücke hintereinander 
übertragen (solange der Bus ansonsten frei ist)?

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
USBman schrieb:

> Ich möchte gerne die Paketgröße optimieren, da ich sie selbst bestimmen
> kann. Laut http://www.beyondlogic.org/usbnutshell/usb4.shtml#Bulk werden
> bei USB 2.0 Full Speed in einem Bulk Transfer entweder 8, 16, 32 oder
> maximal 64 Bytes übertragen.

Wobei „Full Speed“ 12 Mbit/s sind, also das, was es schon in USB 1.1
gab.  USB 2.0 „High Speed“ kann auch 512 Bytes.

Die Angabe „ein FTDI“ ist dahingehend nicht eindeutig, es gibt von
FTDI sowohl Klassiker mit Full Speed, aber auch High-Speed-Devices.

> Außerdem scheint mir, daß die ersten beiden Bytes eines Blocks
> reserviert sind (Wofür?), so daß maximal 62 Bytes übertragen werden
> können.

FTDI-typisch wird in den ersten beiden Bytes eines IN-Pakets immer
der Modem-/Leitungsstatus übertragen.

> Werden die einzelnen 64-Byte-Bulk-Transfers ohne Lücke hintereinander
> übertragen (solange der Bus ansonsten frei ist)?

Soweit ich weiß schon.  Insofern tust du dir keinen Gefallen, große
Datenblöcke zu klein zu zersplittern, denn für jeden neuen Transfer
musst du dann meines Wissens auf den Beginn eines neuen Frames warten,
die bei Full Speed im Raster von 1 ms gestartet werden.

Autor: USBman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für die Antworten, Jörg. Es ist ein FTDI mit „Full Speed“, 
insofern ist hier 64 Bytes wirklich das Maximum pro Bulk Transfer und da 
der FTDI immer die 2 Bytes ergänzt, sogar nur 62 Bytes.

Jörg W. schrieb:
> Soweit ich weiß schon.  Insofern tust du dir keinen Gefallen, große
> Datenblöcke zu klein zu zersplittern, denn für jeden neuen Transfer
> musst du dann meines Wissens auf den Beginn eines neuen Frames warten,
> die bei Full Speed im Raster von 1 ms gestartet werden.

Oh je. Das gibt einen völlig neuen Aspekt!

Pro ms gibt es ein theoretisches Maximum: 12000Bit/ms=1500Bytes/ms

Ein Bulk Transfer hat noch Overhead (einerseits den Handshake beim Start 
und andererseits pro Block mindestens die CSC16). Aber wieviel ist es 
genau?

Dann könnte ich nämlich rechnen: 1500Bytes/(64+Overhead (min. 2))=22

Daraus würde folgen, daß ein Datenblock theoretisch maximal 21*62+30 = 
1332Bytes groß sein sollte, wenn der nächste Datenblock gleich beim 
nächsten Frame übertragen werden soll.

Aber ich habe gelesen, daß man selbst beim freiem USB Bus real keine 22 
Bulk Transfers pro ms bekommt, da er wohl einen Teil für Retries und 
Sonstiges freihält. Wieviel kann man also real bekommen?

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
USBman schrieb:
> Wieviel kann man also real bekommen?

Das kannst du wohl nur messen.

Autor: USBman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> USBman schrieb:
>> Wieviel kann man also real bekommen?
>
> Das kannst du wohl nur messen.

Das hängt ja davon ab,

1) wie groß der Overhead pro Bulk Transfer ist,

2) wie groß der Overhead beim Initialisieren eines neuen Transfers ist 
und

3) wie Bandbreite für Retries und Sonstiges freigehalten wird.

Gibt es hierzu Dokumentation? Oder weiß jemand diese Zahlen?

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Pump doch einfach mal einen Sack voller Daten rüber und miss, wie lange
sie brauchen.

Autor: USBman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das könnte ich machen, aber ich möchte das Ganze theoretisch voll 
durchsteigen.

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dafür gibt es die spec auf USB.org.
Generell 10% der Bandbreite ist reserviert für Control Transfers
Wenn ich mich richtig erinnere ist der Max payload 9 Bulk Transfers bei 
1.1
Aus Anwendersicht schickst du einfach deinen kompletten Buffer in einem 
Rutsch
Der Rest macht der USB Stack. Der ist dafür zuständig die Pakete passend 
aufzuteilen.
Thomas

Autor: Jim M. (turboj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
USBman schrieb:
> Ich habe eine einfache USB-Konfiguration aus Host und Client (ein FTDI),
> wobei der Client große Datenmengen an den Host per "Bulk Transfer"
> überträgt. Der Bus ist also ansonsten frei und unbelastet.

Nur die "Großen" FTDIs mit H Suffix können soviele Daten überhaupt 
aufnehmen, dass man einen USB Full Speed Bus ernsthaft belasten kann. 
Die laufen aber auch mit High Speed!

Die kleinen haben IIRC nur ein 6 MHz Quarz oder entsprechenden 
Oszillator. Da kommen selbst mit MPSSE nicht genug Daten zusammen. 
Außerdem haben die FTDIs selbstverständlich FIFOs eingebaut, was..

> Ich möchte gerne die Paketgröße optimieren, [...]

..zuverlässig verhindert.

Mit USB Bulk Transfers muss man sich nur dann rumschlagen, wenn man auch 
einen µC mit eingebauter USB Hardware verwendet.

Autor: USBman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas schrieb:
> Aus Anwendersicht schickst du einfach deinen kompletten Buffer in einem
> Rutsch
> Der Rest macht der USB Stack. Der ist dafür zuständig die Pakete passend
> aufzuteilen.

Ich möchte so gut an Echtzeit herankommen, wie es mit Bulk Transfer 
geht. Deswegen wollte ich meine Daten zuvor in kleinere Happen 
aufteilen, ohne den Bus zu überschätzen.


Wenn z.B. jede ms 93 Bytes entstehen und ich "schicke das in einem 
Rutsch" per FTDI, dann würden daraus jede ms drei Bulk Transfers werden: 
62+31+0

Ich könnte aber auch alle 2ms 186 Bytes schicken, dann hätte ich 
62+62+62+0 also vier Bulk Transfers. Ergo 33% gespaart.


Jim M. schrieb:
> Nur die "Großen" FTDIs mit H Suffix können soviele Daten überhaupt
> aufnehmen, dass man einen USB Full Speed Bus ernsthaft belasten kann.

Hier http://www.ftdichip.com/FT-X.htm gibt es auch einige, die bis zu 
1MByte/s übertragen können.


Jim M. schrieb:
> Außerdem haben die FTDIs selbstverständlich FIFOs eingebaut, was..
>> Ich möchte gerne die Paketgröße optimieren, [...]
> ..zuverlässig verhindert.

Man kann z.B. den Time-Out konfigurieren, wann ein Bulk Transfer 
gestartet wird.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
USBman schrieb:
> Deswegen wollte ich meine Daten zuvor in kleinere Happen aufteilen, ohne
> den Bus zu überschätzen.

Egal, was du tust: es wird langsamer werden, als wenn du es gleich
dem FTDI überlässt.

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du kannst den Bus nicht überschätzen. Deine Überlegungen sind falsch.
Die Aufteilung macht sowieso der USB Stack bzw in deinem Fall der ftdi 
Treiber.
Da hast du keinen Einfluss. Im Gegenteil short Pakets bremsen den Bus.
Die Packet Größe wird im deskriptor festgelegt die ist fix. Alle 
Transfers die kleiner als diese Paket size sind sind per def. short 
Pakets und stoppen den Transfer.
Bei einem freien Bus kannst du max 9 64Byte pro ms auf die Reise 
schicken.
Das entspricht in etwa 500 kbytes pro sec und ist das was unter 
optimalen Bedingungen unter 1.1 möglich ist. Du kannst die spec nicht 
überlisten.
Echtzeit und Bulk ist übrigens ein Widerspruch in sich. Für Echtzeit ist 
ISO vorgesehen. Du musst dein Konzept überdenken.
Thomas

Autor: USBman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas schrieb:
> Bei einem freien Bus kannst du max 9 64Byte pro ms auf die Reise
> schicken.
> Das entspricht in etwa 500 kbytes pro sec und ist das was unter
> optimalen Bedingungen unter 1.1 möglich ist.

Ich habe Benchmarks unter "Full Speed" gesehen, wo bis 1MByte/s 
übertragen wurde, also 16 Bulk Transfers/ms.

Das liegt noch deutlich unter dem einzigen Wert, den ich finden konnte, 
daß bei Bulk Transfer die tatsächliche Datenrate bis an 88.74% der 
nominellen Rate (12MBit/s) heranreichen kann, also 1331Bytes/ms.

Und letztere Zahl deckt sich wiederum wunderbar mit der von mir oben 
berechneten.


Thomas schrieb:
> Die Aufteilung macht sowieso der USB Stack bzw in deinem Fall der ftdi
> Treiber.

Mein eigener Treiber läuft, daher kann ich auf der untersten Ebene 
eingreifen.


Thomas schrieb:
> Die Packet Größe wird im deskriptor festgelegt die ist fix.

Hm, sie ist wie in meinem Anfangspost geschrieben entweder 8, 16, 32 
oder
maximal 64 Bytes. Vielleicht denkst Du an etwas anderes?


Thomas schrieb:
> Echtzeit und Bulk ist übrigens ein Widerspruch in sich. Für Echtzeit ist
> ISO vorgesehen.

Hierzu hatte ich schon geschrieben, daß außer einem Host und einem 
Client es keine weiteren Geräte gibt, der Bus also ansonsten unbenutzt 
ist. Unter solchen Bedingungen kann ich sehr wohl so etwas wie 
"Echtzeit" erreichen, wenn ich weniger als 20ms Latenz ansetze.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
USBman schrieb:
> Das liegt noch deutlich unter dem einzigen Wert, den ich finden konnte,
> daß bei Bulk Transfer die tatsächliche Datenrate bis an 88.74% der
> nominellen Rate (12MBit/s) heranreichen kann, also 1331Bytes/ms.

Wo findest du diesen Wert?

Ich finde im USB-Standard 1216 Bytes/ms.  Das ist aber eher ein
theoretisches Maximum denn ein praktisch irgendwie erreichter Wert.

Natürlich ist das mit einer Endpoint-Größe von 64 Bytes.  Ich verstehe
gar nicht, warum du, wenn es dir auf Datendurchsatz ankommst, die
kleineren potenziell in Frage kommenden Werte immer wieder vorkramst,
es ist doch sonnenklar, dass es damit nur schlechter werden kann (und
die Tabelle im Standard zeigt das auch deutlich).

Autor: USBman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Ich verstehe
> gar nicht, warum du, wenn es dir auf Datendurchsatz ankommst, die
> kleineren potenziell in Frage kommenden Werte immer wieder vorkramst

Sorry, das lasse ich besser mal.


Jörg W. schrieb:
> (und die Tabelle im Standard zeigt das auch deutlich)

Welche Tabelle? Ich habe z.B. die "Universal Serial Bus Specification" 
Revision 2.0 vom 22. April 2000 hier.


Jörg W. schrieb:
> Wo findest du diesen Wert?

https://de.wikipedia.org/wiki/Universal_Serial_Bus...
und dann 6. Anmerkung unter der Tabelle

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nun dann mach das einfach. Ist ja so einfach. Zeige mir das Design was 
über einen Endpoint mehr als 9 Transfers unter FS macht.
Ich kann dir nur empfehlen die USB spec zu lesen. Dort sind diese Dinge 
beschrieben.
Erreichst du mi deinem Treiber überhaupt die 500 kbytes pro sec? Der 
Demo Bulk Treiber im winddk schaffe diese jedenfalls gerade so......
USB 1.1 bedeutet 12 Mbit am root Hub der damals 2 Ports hatte ergo 6Mbit 
pro Port.
Daraus ergeben sich die 500kbytes wenn man den Overhead abzieht. Dies 
ist genau das was die USB 1.1 spec beschreibt.
Unter 2.0 ist das etwas anderes nur bringt dir das nichts da deine 
Transfers von usbd.sys nach 1.1 abgewickelt werden.

Ich verstehe nicht warum du die spec ignorieren willst. Oder wird das so 
ein Device was manchmal funktioniert. Von dehnen gab es viele und diese 
haben anfangs zum schlechten Ruf von USB beigetragen.

Thomas

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
USBman schrieb:
> Welche Tabelle?

5-9, Seite 54

: Bearbeitet durch Moderator
Autor: USBman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> USBman schrieb:
>> Welche Tabelle?
>
> 5-9, Seite 54

Ja, danke! Die Tabelle liefert genau die Antwort auf meine obige Frage:

USBman schrieb:
> Aber ich habe gelesen, daß man selbst beim freiem USB Bus real keine 22
> Bulk Transfers pro ms bekommt, da er wohl einen Teil für Retries und
> Sonstiges freihält. Wieviel kann man also real bekommen?

19 64-Byte Bulk Transfers sind also pro ms maximal möglich (19*64=1216 
Bytes).

Dort ist auch der gesamte Overhead angedeutet. Wunderbar.

17 wurden in den von mir genannten Benchmarks real erreicht.


Thomas schrieb:
> Erreichst du mi deinem Treiber überhaupt die 500 kbytes pro sec? Der
> Demo Bulk Treiber im winddk schaffe diese jedenfalls gerade so......
> USB 1.1 bedeutet 12 Mbit am root Hub der damals 2 Ports hatte ergo 6Mbit
> pro Port.

Von Windows habe ich nichts gesagt. Und hier geht es um USB 2.0, nicht 
1.1 da mußt Du mal ein bischen die Doku lesen, um den Unterschied zu 
verstehen. Wenn ich "Full Speed" USB 2.0 schreibe, ist alles gesagt.

Ein guter Host mit mehreren Ports teilt seine Bandbreite nicht durch die 
Anzahl der Ports, sondern liefert dem Port, der Bandbreite braucht, so 
viel wie gefordert und möglich. Bei nur einem benutzen Port dann eben 
bis zu 12MBit. Du redest da über irgendeinen Sonderfall von Anno 
Dazumal. Warum muß denn jede ernstgemeinte Frage hier immer torpediert 
werden?

Meine Hard- und Software läuft schon seit Monaten an verschiedenen 
Geräten, jetzt wollte ich die gefundenen Grenzen theoretisch 
hinterfragen, weil ich die Dinge gerne durch und durch verstehe.

Autor: USBman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
USBman schrieb:
> Jörg W. schrieb:
>> Wo findest du diesen Wert?
>
> https://de.wikipedia.org/wiki/Universal_Serial_Bus...
> und dann 6. Anmerkung unter der Tabelle

Der Wert 88.74% stammte auch aus Tabelle 5-10 auf S.55 (512*13/7500) und 
ist daher nur für High Speed gültig. Für Full Speed, wie Du, Jörg 
richtig sagst, die Tabelle 5-9 und damit 64*19/1500 = 81%.

Das könnte man in der wikipedia-Fußnote natürlich mal präzisieren.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
USBman schrieb:
> Das könnte man in der wikipedia-Fußnote natürlich mal präzisieren.

Mach doch: genau dafür ist das doch ein Wiki.

Autor: USBman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch eine Ergänzung:

Der Unterschied von 88.7% zu 81% (=7.7%) wird fast vollständig durch den 
Anteil an Overhead-Bytes pro Bulk Transfer erklärt, der zwischen Full 
und High Speed besteht:

High Speed: 512/(512+55) = 90.3%

Full Speed: 64/(64+13) = 83.1%

=7.2%

Autor: USBman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg, Jim und auch Thomas, vielen Dank für die Gedankenanstöße. Mir hat 
die Diskussion hier viel geholfen und ich bin jetzt schlauer als am 
Anfang.

Autor: Jim M. (turboj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas schrieb:
> Erreichst du mi deinem Treiber überhaupt die 500 kbytes pro sec? Der
> Demo Bulk Treiber im winddk schaffe diese jedenfalls gerade so......
> USB 1.1 bedeutet 12 Mbit am root Hub der damals 2 Ports hatte ergo 6Mbit
> pro Port.
> Daraus ergeben sich die 500kbytes wenn man den Overhead abzieht. Dies
> ist genau das was die USB 1.1 spec beschreibt.

Nö. Schreibt sie nicht. Da wird übrigens nix aufgeteilt, solange da 
nicht zufällig 2 Devices den Bus zugleich auslasten.

Deine 500 kBit/s kommen von zu schwachem USB Gerät oder hirntotem 
Windoof Programmierer. M$ ist mal nicht schuld, die 1MBit/s erreicht 
deren Mass storage Treiber.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.