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)
:
Bearbeitet durch User
Timmo H. schrieb: > wenn du für deine Applikation mal die Timer Resolution hoch stellst (via > NtSetTimerResolution) Das geht auch über die "Multimedia"-Timer-Funktionen timeBeginPeriod und timeEndPeriod. Damit lässt sich die Timergranularität auf 1 msec heruntersetzen. https://docs.microsoft.com/en-us/windows/desktop/api/timeapi/nf-timeapi-timebeginperiod https://docs.microsoft.com/en-us/windows/desktop/api/timeapi/nf-timeapi-timeendperiod
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.
:
Bearbeitet durch User
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.html http://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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.