Ich probiere, eine Echtzeitsteuerung mit einem Signalverarbeitungssystem
auzuziehen, das mit einem PC kommunizieren soll. Der PC muss dazu kleine
Pakete im Bereich von 5kB-10kB durchschnittlich alle 10-20ms aufnehmen
und verarbeiten / speichern, d.h. er pickt sich was raus und reagiert
dann darauf. Die maximale Dichte der Pakte ist etwa 3ms.
Die Bandbreite liegt also bei maximal punktuellen 10kB/3ms < 30MBit.
Vorgesehen ist USB 2.0. Sollte also passen, meint man.
Das Problem ist aber, dass Windows irgendwie nicht schnell genug
reagiert und es z.T. 10ms dauert, bis die Pakete oben ankommen und
abgearbeitet sind.
Die Rechenleistung für den Prozessor beträgt 10-20 Aktionen je Datum,
macht also 70 Mio Berechnungen/s. Das kann es nicht sein. Die Lücke muss
irgendwo auf dem Weg zum Treiber aufgehen. Auch die Belastung des Cores
liegt maximal bei 10%, im Mittel bei 2-3%.
Wie lässt sich das erklären beschleunigen umgehen?
Verwendet wird ein Quad-Core I% mit 2,8GHz. Umstieg auf einen
8er-Mehrkerner mit 4GHz zeigt ähnliche Resultate.
Kann es am Windows liegen? Beide Rechner haben noch Windows 7 drauf.
Kann man sich von Win10 mehr versprechen?
Was ist das für ein Gerät? Was für Endpoints nutzt du? Wie sind die
konfiguriert (Deskriptoren)? Sicher dass die Software vom Gerät schnell
genug reagiert?
> Wie lässt sich das erklären beschleunigen umgehen?
Echtzeit, USB, Windows - finde die 2 (zwei!) Fehler!
Auch wenn die Zahlen überschlagsmässig genug Reserve vorgaukeln, hast Du
schon mal gesehen wie überkandidelt USB vom Konzept her ist? Und
Windows auch?
Ja? Also dann überlege mal an wievielen Stellen mögliche
Schlampereien oder gar Fehler möglich sind. Dann führe Dir vor Augen an
wievielen Stellen Variablen sind UND wieviele davon ausserhalb deines
Einflusses sind.
Um dagegen anzugehen resp. einige davon gar nicht zu haben, wäre
"möglicherweise" eine andere Technologiekombination geeigneter um
Echtzeitansprüche zu erfüllen.
Ansonsten hast Du nun ja eine Idee davon, wieviel Arbeit Du noch zu
bewältigen hast...
NB: dieselbe Frage vor einigen Jahren gestellt, also ohne Windows X+1 im
Ausblick, hätte die selbe Antwort bekommen. Weil Bloatware schneller
Bloat wird als HW schneller.
Martin K. schrieb:> Das Problem ist aber, dass Windows irgendwie nicht schnell genug> reagiert und es z.T. 10ms dauert, bis die Pakete oben ankommen und> abgearbeitet sind.
Wie sind die USB Pakete aufgebaut? Volle Pakete (MaxPacketLength bei
Bulk) bekommt der Host erst dann zurück, wenn mal ein Paket
<MaxPacketLength versendet wurde (oder Puffer voll sind).
Wenn man genau MaxPacketLength übertragen will müsste man ein
Zero-Packet nachschieben. Das macht kaum ein USB Stack automagisch.
Pit Cock schrieb:> Echtzeit, USB, Windows - finde die 2 (zwei!) Fehler!
Ich hatte mal spaßenshalber Ping Messungen mit LibUSB-Win32 gemacht, und
kam auf so rund 1.25ms Ping Zeit bei USB Full Speed (12MBit/s).
Allerdings nur wenn man die Read Transaktion vor der Write Transaktion
startet - sonst dauert das noch rund 1-2 ms länger IIRC.
Den Paketaufbau muss ich mal checken lassen, keine Ahnung. Die anderen
beiden Beiträge bringen mich aber schon mal weiter, auch wenn das kein
erbaulichen Infos sind.
Ich würde gerne die Reaktionszeiten auf 1ms beschränken, aber das ist
wohl utopisch.
10ms hört sich eher so nach dem Thread Time Slice an. Kein Plan ob es
was ändert wenn du für deine Applikation mal die Timer Resolution hoch
stellst (via NtSetTimerResolution)
Ansonsten evtl. über PerformanceCounter (erzeugt aber höhere CPU-Last)
Martin K. schrieb:> Das Problem ist aber, dass Windows irgendwie nicht schnell genug> reagiert und es z.T. 10ms dauert, bis die Pakete oben ankommen und> abgearbeitet sind.
Gebetsmühle an:
Windows ist kein Echtzeit-OS. Wenn der Taskwechsel schon nominell nur
alle 20ms erfolgt, kann man nicht erwarten, Zeiten im Bereich darunter
exakt messen zu können. Das sollte jedem denkenden Menschen von
vornherein klar sein...
Um Diskrimierungen von Windows vorzubeugen: das gilt für Linux ganz
genauso.
Für beide Systeme gibt es allerdings "Echtzeit"-Aufsätze. Und auch
diverse andere Möglichkeiten, sich in die Nähe von "Echtzeit" zu
schummeln.
Ist aber alles mehr oder weniger Gülle. Die "Echtzeit"-Aufsätze können
zwar wirklich Echtzeit (solange auch alle Treiber mitspielen), aber
diese Echtzeit ist lahm. Viel zu lahm, Zeiten um 10ms exakt erfassen zu
können.
Und die Tricks sind eben nicht Echtzeit, können also kein exaktes
Zeitverhalten garantieren. Allerdings kann man damit unter günstigen
Umstanden Zeiten im Bereich von 10ms wirklich messen. Aber was nützt
das, wenn man dem Messergebnis nicht wirklich trauen kann?
Es gibt ein paar Stellschrauben, wo man etwas relevant optimieren kann.
Allerdings ist Windows nicht geeignet, es wird am Ende höchstens mit
viel Glück funktionieren. Dabei ist USB nur ein problem, du wirst
ähnliche Delays bei allen anderen denkbaren Schnittstellen ebenso
erleben, weil dein Programm nicht ununterbrochen ganz alleine auf dem
Rechner läuft.
Was kann man machen?
Die Daten mit einem externen Mikrocontroller puffern und dann an den PC
senden. Du musst aber eine andere Schnittstelle verwenden, mindestens
USB 2.0 Hi-Speed, das bietet kein USB-UART Adapter, soweit ich weiß.
Das wird so nix. Weder Windows noch USB sind Echtzeit fähig. Selbst wenn
du einen RTOS Kernel für Windows verwendest wird dir die USB Topologie
in die Suppe spucken.
Man hat ja schon am Host Controller keine deterministischen Zeiten, am
Root Hub nicht und am Treiber Stack erst recht nicht.
Etwas besser geht Interrupt statt BULK Transfer aber dann ist die
Datenrate natürlich nicht so hoch.
Was soll das Ganze denn koennen ? Wir suchen dir ne Alternative. Der PC
kann leider nur als langsames Visualisierungs- und
Parametrisierungs-Frontend dienen.
Stefanus F. schrieb:> mindestens> USB 2.0 Hi-Speed, das bietet kein USB-UART Adapter, soweit ich weiß.
Der FT232H bietet im Prinzip schon Hi-Speed USB an.
Allerdings ist die Baudrate im Vergleich zur USB-Geschwindigkeit stark
limitiert. Wenn man damit schneller werden möchte muss man eine andere
Schnitstelle auf der Mikrocontroller Seite nutzen.
Siehe:
http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT232H.pdf
Martin K. schrieb:> Die Bandbreite liegt also bei maximal punktuellen 10kB/3ms < 30MBit.> Vorgesehen ist USB 2.0. Sollte also passen, meint man.
Die USB-Spec ist da ein bisschen tricky: USB 2.0 ist eine Obermenge von
USB 1.1, 1.0.
Ein Gerät, das mit "USB 2.0" beworben ist, kann also auch nur ein Low
Speed, oder Full Speed (12 Mb/s) Gerät sein. "USB 2.0" sagt zunächst
nichts über die Geschwindigkeit aus. Stattdessen musst du auf
"Super-Speed", "Hi-Speed", "Full Speed", "Low Speed" achten.
Zum Beispiel ist der FT230X "Full Speed" (12 Mb/s) und der FT2232H "Hi
Speed" (480 Mb/s). Beide sind USB 2.0.
http://www.ftdichip.com/Products/ICs/FT230X.htmlhttp://www.ftdichip.com/Products/ICs/FT2232H.html
Bei den Datenraten muss aber noch der USB Protokolloverhead
berücksichtigt werden und Aussagen über USB-bedingte Latenzen/Jitter
sind das auch nicht.
c-hater schrieb:> Martin K. schrieb:>>> Das Problem ist aber, dass Windows irgendwie nicht schnell genug>> reagiert und es z.T. 10ms dauert, bis die Pakete oben ankommen und>> abgearbeitet sind.
[...]
> Für beide Systeme gibt es allerdings "Echtzeit"-Aufsätze. Und auch> diverse andere Möglichkeiten, sich in die Nähe von "Echtzeit" zu> schummeln.>> Ist aber alles mehr oder weniger Gülle. Die "Echtzeit"-Aufsätze können> zwar wirklich Echtzeit (solange auch alle Treiber mitspielen), aber> diese Echtzeit ist lahm. Viel zu lahm, Zeiten um 10ms exakt erfassen zu> können.
Es gibt schon Möglichkeiten mit normalen amd64 CPUs niedrige und
deterministische Latenzen hinzubekommen. Habe zum Beispiel für die
Arbeit mal einen Netzwerk-Paketgenerator (nicht USB!) unter Linux-RT mit
DPDK (https://www.dpdk.org/) gebaut und dabei Latenzen von CPU zum Kabel
um die 8-9 µs erreicht, mit Paket-zu-Paket Jitter Standardabweichung < 1
µs. (das ist so grob das Minimum, was mit DPDK erreichbar ist)
Das erreicht man z.B. in dem dynamic CPU frequency scaling abgeschaltet
wird, auf jedem Echtzeit-Kern nur ein thread laufen darf (isolcpus boot
option und fixe affinities setzen), Speicher im "nahen" RAM alloziert
wird (NUMA), huge pages, sowie DPDK als user-space IP stack (keine
Latenzen durch OS Kernel, user-space Prozess kommuniziert direkt mit
Netzwerkkarte), sowie eine 10 GbE Netzwerkkarte.
Der thread auf einem CPU-Kern macht ausschließlich busy waiting und
möglichst keine syscalls; die CPU-Last ist dann konstant bei 100%...
Also möchte damit sagen: Prinzipiell kann man schon ganz passable
Ergebnisse erzielen, aber es sind schon sehr spezielle Anwendungen bei
denen das geht und für die es Werkzeuge gibt. Zudem hat USB halt
designbedingt einen relativ großen Jitter.
Jiri D. schrieb:> Das erreicht man z.B. in dem dynamic CPU frequency scaling abgeschaltet> wird, auf jedem Echtzeit-Kern nur ein thread laufen darf (isolcpus boot> option und fixe affinities setzen), Speicher im "nahen" RAM alloziert> wird (NUMA), huge pages, sowie DPDK als user-space IP stack (keine> Latenzen durch OS Kernel, user-space Prozess kommuniziert direkt mit> Netzwerkkarte), sowie eine 10 GbE Netzwerkkarte.
Ich lese das gerade mit und frage mal frech dazwischen:
Wo kann man sowas ablesen oder erlernen? Buch- oder Seitenempfehlung
parat?
Danke!
Julia D. schrieb:> Jiri D. schrieb:>> Das erreicht man z.B. in dem dynamic CPU frequency scaling abgeschaltet>> wird, auf jedem Echtzeit-Kern nur ein thread laufen darf (isolcpus boot>> option und fixe affinities setzen), Speicher im "nahen" RAM alloziert>> wird (NUMA), huge pages, sowie DPDK als user-space IP stack (keine>> Latenzen durch OS Kernel, user-space Prozess kommuniziert direkt mit>> Netzwerkkarte), sowie eine 10 GbE Netzwerkkarte.>> Ich lese das gerade mit und frage mal frech dazwischen:>> Wo kann man sowas ablesen oder erlernen? Buch- oder Seitenempfehlung> parat?
Bezüglich DPDK in der dazugehörigen Dokumentation:
http://core.dpdk.org/doc/
-> Getting started guide for Linux:
http://doc.dpdk.org/guides/linux_gsg/
-> Programmer's Guide
http://doc.dpdk.org/guides/prog_guide/
Da sind auch Beispiele dabei (in C), die aber teilweise echt konfus
sind...
Martin K. schrieb:> Ich würde gerne die Reaktionszeiten auf 1ms beschränken, aber das ist> wohl utopisch.
Nö. Ich habe <1ms "Ping" (im Mittel) gemessen als ich mein Full Speed
Gerät hinter einen High Speed Hub gehangen habe. Gab aber IIRC
signfikant Ausreisser nach oben.
Allerdings war das mit "direkter" Programmierung über LibUSB-Win32, und
überschneidendem Lese- und Schreibtransfers - d.h. der Lese-Transver
wurde vor dem Schreibtransfer gestartet.
Dann darf aber auch kein USB2UART Chip mehr dazwischen hängen. Die
warten gerne mal so 1-10ms auf Daten, um die dann aus dem Fifo in einem
Rutsch zu versenden - spart Ressourcen auf dem Host. Grade neuere FTDI
Chips haben vergleichsweise große Fifos auf dem UART.
Glücklicherweise gibt es bei den meissten µC Familien Ableger mit
nativem USB.
Christian R. schrieb:> Das wird so nix. Weder Windows noch USB sind Echtzeit fähig. Selbst wenn> du einen RTOS Kernel für Windows verwendest wird dir die USB Topologie> in die Suppe spucken.
Ich glaube es auch. Nur bin ich eben an Windows gebunden.
Danke für all eure Beiträge. Hat mich weiter gebracht!
Martin K. schrieb:> Christian R. schrieb:>> Das wird so nix. Weder Windows noch USB sind Echtzeit fähig. Selbst wenn>> du einen RTOS Kernel für Windows verwendest wird dir die USB Topologie>> in die Suppe spucken.>> Ich glaube es auch. Nur bin ich eben an Windows gebunden.>> Danke für all eure Beiträge. Hat mich weiter gebracht!
USB ist natürlich echtzeitfähig. Es ist in Zeitscheiben von 1ms
(Full Speed), bzw 0.125 ms (High Speed) organisiert.
Also alle 0.125 ms wird ein Packet gesendet und empfangen.
Der Windows Treiber funktioniert mit DMA parallel zur CPU,
sodass das Windows auf USB Treiberebene in der Praxis
ebenfalls echtzeitfähig ist.
Also ein Ping-Pong von <= 2ms läuft auf nicht ausgelasteten
Windows Rechnern meiner Erfahrung nach stabil.
Es kann aber sein, dass dein Anwenderprogram (User Thread)
mal nicht zum Abarbeiten der Packete kommt,
wenn Windows andere User Threads mit höherer Prio abarbeitet.
Das kannst du relativ leicht umgehen, indem du vor zeitkritischen
Aktionen ein Sleep() aufrufst, sodass dein Thread, wenn er
aufwacht, immer den ganzen Zeitschlitz zur verfügung hat, und indem du
die Basispriorität erhöhst.
Also, wenn du nur auf Packet N innerhalb von 10 ms antworten musst,
ist das unter Windows in der Praxis kein Problem.
So ziemlich alle Audio Interfaces habe weniger als 10 ms Latenz.
udok schrieb:> USB ist natürlich echtzeitfähig. Es ist in Zeitscheiben von 1ms> (Full Speed), bzw 0.125 ms (High Speed) organisiert.> Also alle 0.125 ms wird ein Packet gesendet und empfangen.
Betrachtungsfrage! Die 0.125ms würde ich noch als Echtzeit durchgehen
lassen, bei den 1ms habe ich so mein Problem.
Für den Fall der geringen Paketgrößen mit pulsierenden Daten in kleinem
Umfang bekomme ich das nicht geregelt, den Puffer vollzuladen, dass
gesendet wird.
Stellt sich die Frage, was alternativ nehmen, wenn nicht USB?
Martin K. schrieb:> udok schrieb:>> USB ist natürlich echtzeitfähig. Es ist in Zeitscheiben von 1ms>> (Full Speed), bzw 0.125 ms (High Speed) organisiert.>> Also alle 0.125 ms wird ein Packet gesendet und empfangen.>> Betrachtungsfrage! Die 0.125ms würde ich noch als Echtzeit durchgehen> lassen, bei den 1ms habe ich so mein Problem.
Eigentilch nicht. "Echtzeitfähig" sagt ja nichts über die
Geschwindigkeit aus sondern garantiert eine Verarbeitung innerhalb einer
gewissen Zeit.
Zumindest hab ich das mal so gelernt, habe diese Definition aber auch
immer wieder so angetroffen.
Und USB stellt auch Real Time Transfers zur Verfügung. Da gehen zwar
keine maximalen Datenraten und ich meine, eine Rückmeldung über
fehlerhaft übertragene Pakete gibt es auch nicht oder nur eingeschränkt,
aber grundsätzlich ist USB schon echtzeitfähig.
Nur das fette Windows eben nicht. Wenn es "in den meisten Fällen"
schnell genug reagiert, so ist das auch ganz schnell mal hinfällig wenn
der Benutzer z.B. eine CD ins Laufwerk schiebt.
Martin K. schrieb:> Stellt sich die Frage, was alternativ nehmen, wenn nicht USB?
Man macht die Echtzeit-Aufgabe komplett auf dem Controller/Gerät, und
macht auf dem PC nur die Nutzerschnittstelle und falls nötig die
Versorgung mit großen, nicht-echtzeitkritischen Daten (Logging,
Aufspielen von "Programmen" wie ganze CNC-Programme, ...). So wie bei
Druckern: Der PC schickt das ganze Dokument (z.B. als Postscript)
beliebig langsam, und wenn es angekommen ist besorgt der Drucker die
zeitkritische Ansteuerung von Druckkopf und Motoren.
Naja, echtzeitfähig kann ja auch sein, dass es garantiert in 3 Tagen
reagiert.
Bis zum Host Controller würde ich da, zwar mit Bauchschmerzen, mitgehen.
Aber dann wirds lustig. Wenn die Daten da sind, wird ein Interrupt
generiert. Den arbeitet der Interrupt Controller irgendwann ab und
signalisiert dem OS Kernel, dass da was zu tun ist. Irgendwann kommt der
Kernel Scheduler mal vorbei und holt die Daten ab. Irgendwann wird dann
mal die Anwendung im user Space benachrichtigt. Bei USB Interrupt oder
Isochron Transfer bekommt man noch garantierte Bandbreiten (die
natürlich weit weniger sind als der Maximaldurchsatz), aber wenn man
schnell übertragen will, muss man BULK nehmen, das hat aber die
niedrigste Priorität. Wir haben hier bei Windows Pausen im Datentransfer
von 50...100....200ms festgestellt, obwohl die Hardware kontinuierlich
Daten liefert und der PC massig Kerne hat und nichts zu tun.
Dr. Sommer schrieb:> So wie bei> Druckern: Der PC schickt das ganze Dokument (z.B. als Postscript)> beliebig langsam, und wenn es angekommen ist besorgt der Drucker die> zeitkritische Ansteuerung von Druckkopf und Motoren.
Ich hatte mal einen Laserdrucker, der nur eine halbe Seite puffern
konnte. Mit diesem Gerät hatte ich ständig Probleme. Am Schlimmsten war,
wenn er beim Drucken von Büchern einzelne Absätze ausgelassen hatte. Ein
scheußliches Gerät war das.
Christian R. schrieb:> Bei USB Interrupt oder Isochron Transfer bekommt man noch garantierte> Bandbreiten (die natürlich weit weniger sind als der Maximaldurchsatz),> aber wenn man schnell übertragen will, muss man BULK nehmen, das hat> aber die niedrigste Priorität.
Das steht in USB spec. aber anders.....
Bulk ist genau nicht für die schnellsten Datentransfers gedacht sondern
dafür garantiert fehlerfrei. Auf einem freien Bus ist Bulk genauso
schnell wie ISO.
Schlechte Verbindungen (Kabel, Hubs) können dafür sorgen dass es
langsamer wird. Oft kann einfach das device die Daten nicht schnell
genug verarbeiten und sendet NAKs.
Nicht um sonst gibt es Chips mit 2fach oder sogar 4fach Puffer.
Thomas
Thomas schrieb:> Auf einem freien Bus ist Bulk genauso schnell wie ISO.
ISO liefert mir bei 2.0 eine garantierte Bandbreite von 24MByte/s. BULK
schafft bei freiem Bus knapp über 40MByte/s.
Christian R. schrieb:> Naja, echtzeitfähig kann ja auch sein, dass es garantiert in 3 Tagen> reagiert.
Na ja, jetzt übertreibst du aber etwas, wenn mein Windows nach 3 Minuten
nix mehr macht, drücke ich den Reset.
> Bis zum Host Controller würde ich da, zwar mit Bauchschmerzen, mitgehen.> Aber dann wirds lustig. Wenn die Daten da sind, wird ein Interrupt> generiert. Den arbeitet der Interrupt Controller irgendwann ab und> signalisiert dem OS Kernel, dass da was zu tun ist. Irgendwann kommt der> Kernel Scheduler mal vorbei und holt die Daten ab. Irgendwann wird dann> mal die Anwendung im user Space benachrichtigt.
Wenn der Interrupt da ist, dann arbeitet der IRQ Controller
ihn sofort ab.
Der IRQ Controller ruft dann den Scheduler auf, der merkt dass
Daten, auf die der User Prozess wartet, da sind.
Er ruft dann den User Prozess direkt auf.
Das dauert keine Millisekunde.
> Bei USB Interrupt oder> Isochron Transfer bekommt man noch garantierte Bandbreiten (die> natürlich weit weniger sind als der Maximaldurchsatz), aber wenn man> schnell übertragen will, muss man BULK nehmen, das hat aber die> niedrigste Priorität.
Die Isochrone Bandbreite ist ca die Hälfte der maximalen Bandbreite,
also nicht so viel weniger wie man in der Praxis im Bulk Mode erreicht.
Wenn nur ein Gerät am Bus hängt, wie es ja oft der Fall ist,
dann kannst du einfach Bulk Mode nehmen, da der USB Bus ja nicht
willkürlich Delays einbaut...
> Wir haben hier bei Windows Pausen im Datentransfer> von 50...100....200ms festgestellt, obwohl die Hardware kontinuierlich> Daten liefert und der PC massig Kerne hat und nichts zu tun.
Wenn du einen Windows Hintergrundprozess laufen hast, von denen manche
hohe Prio haben, dann muss dein User Prozess halt warten, bis
die Festplatte indiziert hat, oder Updates runterlädt,
oder was auch immer...
Die kann man aber abdrehen.
Christian R. schrieb:> Thomas schrieb:>> Auf einem freien Bus ist Bulk genauso schnell wie ISO.>> ISO liefert mir bei 2.0 eine garantierte Bandbreite von 24MByte/s. BULK> schafft bei freiem Bus knapp über 40MByt
Das liegt daran, das nur ca die Hälfte der Bandbreite für ISO
rerserviert
werden kann.
Ich mache andauernd Echtzeitdinge. Auch komplexe. Dabei lass ich den
steuernden Prozess auf einem Controller laufen, und benutze den PC nur
zur Parametrisierung und Visualisierung. Zur Anbindung des Controllers
an einen PC..
Falls es denn USB sein muss, USB-to-Serial kann soviel wie eben die
passenden Controller von FTDI koennen. Dabei sollte man fuer maximaelne
Durchsatz grosse Blocklaengen verwenden. Uns kleine Ping-Pong
Geschichten vermeiden.
Fuer hoehere Datenraten, zB Oszilloskopbilder, verwendet man Ethernet.
udok schrieb:> Christian R. schrieb:>> Naja, echtzeitfähig kann ja auch sein, dass es garantiert in 3 Tagen>> reagiert.>> Na ja, jetzt übertreibst du aber etwas, wenn mein Windows nach 3 Minuten> nix mehr macht, drücke ich den Reset.
Es ging mir nur darum, den Unterschied zwischen "echtzeitfähig" und
niedrige Latenz bzw. hoher Datendurchsatz zu erläutern. Da wird ja immer
viel vermischt.
>> Bis zum Host Controller würde ich da, zwar mit Bauchschmerzen, mitgehen.>> Aber dann wirds lustig. Wenn die Daten da sind, wird ein Interrupt>> generiert. Den arbeitet der Interrupt Controller irgendwann ab und>> signalisiert dem OS Kernel, dass da was zu tun ist. Irgendwann kommt der>> Kernel Scheduler mal vorbei und holt die Daten ab. Irgendwann wird dann>> mal die Anwendung im user Space benachrichtigt.>> Wenn der Interrupt da ist, dann arbeitet der IRQ Controller> ihn sofort ab.> Der IRQ Controller ruft dann den Scheduler auf, der merkt dass> Daten, auf die der User Prozess wartet, da sind.> Er ruft dann den User Prozess direkt auf.> Das dauert keine Millisekunde.
Naja, in der Theorie mag das so sein, unsere Erfahrung aus über 10
Jahren USB Messgeräte Entwicklung sagt da leider was anderes.
>> Bei USB Interrupt oder>> Isochron Transfer bekommt man noch garantierte Bandbreiten (die>> natürlich weit weniger sind als der Maximaldurchsatz), aber wenn man>> schnell übertragen will, muss man BULK nehmen, das hat aber die>> niedrigste Priorität.>> Die Isochrone Bandbreite ist ca die Hälfte der maximalen Bandbreite,> also nicht so viel weniger wie man in der Praxis im Bulk Mode erreicht.> Wenn nur ein Gerät am Bus hängt, wie es ja oft der Fall ist,> dann kannst du einfach Bulk Mode nehmen, da der USB Bus ja nicht> willkürlich Delays einbaut...
Der Bus nicht, das OS aber schon.
>> Wir haben hier bei Windows Pausen im Datentransfer>> von 50...100....200ms festgestellt, obwohl die Hardware kontinuierlich>> Daten liefert und der PC massig Kerne hat und nichts zu tun.>> Wenn du einen Windows Hintergrundprozess laufen hast, von denen manche> hohe Prio haben, dann muss dein User Prozess halt warten, bis> die Festplatte indiziert hat, oder Updates runterlädt,> oder was auch immer...> Die kann man aber abdrehen.
Wie geschrieben, wir entwickeln und vertreiben seit über 10 Jahren USB
Messgeräte bei denen es auf die maximale Geschwindigkeit ankommt.
Dazu verwenden wir den Cypress FX2 und FX3. Auch wenn du alles im
Windows abdrehst und einen Rechner mit 16 Kernen hast, wirst du solche
Pausen rein bekommen. Bei Windows 10 ist es schon um einiges besser als
Windows 7 und erst recht im gruseligen XP, aber weg bekommt man die
Pausen nie.
Wir verwenden WinUSB mit RAW_IO und vielen asynchronen Transfers mit
großer Blocklänge bei BULK, auf der Device Seite maximal mögliche
Buffergröße plus Buffer im FPGA, denn die 4-fach Packet Buffer gerade
des FX2 sind ja immer noch ein Witz und laufen in µs voll.
Wir schaffen damit bei USB 2.0 knapp über 40MiByte/s Upstream und bei
USb 3.0 etwas über 300MiByte/s. Da ginge vielleicht noch was, aber der
FX3 Parallelbus läuft über 85MHz nicht mehr so dolle.
Im Übrigen ist das sehr stark Host-Controller abhängig. ASMedia, VIA
kannste gleich komplett vergessen. Am Besten immer noch Intel EHCI bzw.
xHCI, dicht gefolgt von Renesas. AMD Chipsatz USB 3.0 taugt leider auch
nicht viel, wahrscheinlich sparen die dann an den Buffern.
Christian R. schrieb:>> Wenn der Interrupt da ist, dann arbeitet der IRQ Controller>> ihn sofort ab.>> Der IRQ Controller ruft dann den Scheduler auf, der merkt dass>> Daten, auf die der User Prozess wartet, da sind.>> Er ruft dann den User Prozess direkt auf.>> Das dauert keine Millisekunde.>> Naja, in der Theorie mag das so sein, unsere Erfahrung aus über 10> Jahren USB Messgeräte Entwicklung sagt da leider was anderes.
Ja, eben das ist das Problem. Wir haben in der Softwareabteilung jetzt
Messungen gemacht. Dort sieht man in der Tat die Pausen, von denen du
schreibst.
Danke für den Tipp mit den Interfacebausteinen. War mir nicht bewusst,
dass es dort solche Unterschiede gibt.
