|
Anzeige
|
Ethernet: Wie kann ich die Antwortzeit verkürzen?
Gast
#4222503
Hallo. Implementiere gerade Ethernet auf einem STM32F4. Soweit läuft die Kommunikation per UDP zwischen Windows-PC und STM32 stabil. Nur für meine Gefühle etwas langsam. Eine komplette Kommunikation liegt so bei 1-2ms. (1xUDP PC->STM32 & 1x UDP STM32->PC) Die Firmware hab ich schon "vermessen". Die Antwort geht nach weniger als 100us wieder zurück. (Nur wenige Bytes). Wo bleibt die Zeit? Kann man da was verkürzen? Vielen Dank schon mal. Pepe. Pepe schrieb: > Wo bleibt die Zeit? Da würde ich mal ganz stark auf Windows tippen. > Kann man da was verkürzen? Keine einzelnen Bytes. Möglichst viel Nutzinformation in eine Übertragung.
Gast
#4222523
Karl H. schrieb: > Möglichst viel Nutzinformation Habe ich schon möglichst versucht. Aber leider hat das Zusammenfassen bei meiner Anwendung (Ansteuerung von einzelnen Achsen) bald seine Grenzen erreicht. Gibt's irgendwelche Erfahrungswerte, wo man da zeitlich raus kommen könnte? Ich denke im allgemeinen versucht man, die zeitkritischen Sachen auf dem Microcontroller zu machen (die sind für sowas schliesslich da) und den PC mit all seinen Störmöglichkeiten nur für die zeitunkritisch(er)en Aufgaben zu verwenden...
Gast
#4222579
@Andreas K. Ausgangssituation sind Achscontrollerkarten, die direkt im PCI Bus stecken und somit Responsezeiten <200us haben. Jetzt sind wir dabei auf eine Ethernet-Lösung umzuziehen, da es mit den Karten ziemliche Einschränkungen gibt. Einen ziemlich großen Teil der Aufgaben haben wir schon im Mikrocontroller, aber es bleiben dummerweise noch einige Punkte, die nicht dort laufen können. Da z.B. auf dem PC noch ne Bildverarbeitung läuft und wir live auf die Ergebnisse reagieren müssen, können die Mikrocontroller nicht vollständig autark laufen.
Gast
#4222601
Muss es Windows sein? Man könnte ja auch mal ein kleines schlankes Linux probieren.
Gast
#4222621
Karl H. schrieb: > Da würde ich mal ganz stark auf Windows tippen. Vermutlich, hängt aber auch stark davon ab, welche APIs man unter Windows verwendet. Meiner Erfahrung nach bekommt man die beste Performance mit overlapped Socket I/O in Verbindung mit I/O completion routines.
Gast
#4222623
Hallo, ich hab mal eine Wireshark Datei angehängt. PC W7 sendet Multicast Antwort von neun WizNet5500 angebunden über SPI 8MHz an ATXmega8E5@32MHz Responstime 219µs <= 285µs Auf Adapter prüfen ob Interruptdämpfung aus ist. Heißt von Adapter zu Adapter unterschiedlich oder man kann es nicht einstellen. UDP wird über Interrupt an Adapter übertragen. (Meines Wissens) Hat bei mir ca. 30% Geschwindigkeitsgewinn gebracht bei kontinuierlichem Stream.
Gast
#4222644
@ThomasF Wie hast Du die Sende/Empfangsroutine unter Windows implementiert? Scheint wohl bei mir das größte Problem zu sein.
Gast
#4222674
@Pepe Ist in C#. Wie hast Du gemessen? Im Programm habe ich noch keine Zeitmessung für die Antwortzeit durchgeführt. Bei mir kommt es auf einen kontinuierlichen Stream an. PC->MC. 9 * 724 Byte im 10ms Intervall. (Gemessen im Programm 1.2ms bis alle Daten gesendet wurden.( SockData.SendBufferSize = 0; kein Sendepuffer damit das Ergebnis nicht verfälscht wird)
Gast
#4222678
Hab im Programm gemessen. Da komme ich auf Zeiten von 1.5-3ms. Rein im Wireshark habe ich 600-700us. Interruptdämpfung heißt bei meinem Treiber Interuptdrosselung. Geh davon aus, dass dies das gleiche ist. Hat aber auch nach Neustart keinen Unterschied gebracht.
Gast
#4222686
Ich habe für diesen Zweck einen eigenen Adapter. Alles abgewählt außer Internetprotokoll V4. Ist ein "Intel(R) Gigabit-CT-Desktopadapte" angebunden über PCI-Express.
Gast
#4222704
Ich hab den Stream mal aufgezeichnet. Im Wireshark sind es ca. 600µs (1.2ms ist der Durchschnitt)
Gast
#4222750
Wenn du weniger als 1ms brauchst, brauchst du eine andere Schnittstelle und ein anderes Betriebsystem. Denn beide sind nicht für Verarbeitungsintervalle unter 1ms vorgesehen. Sicher kann man die ein oder anderen Tricks anwenden. Aber du wirst ganz schnell auf andere Ursachen stossen, die das Timing zumindest zeitweise versauen. Linux, Mac OS und Solaris sind dafür IMHO auch nicht besser geeignet.
Gast
#4223067
Stefan U. schrieb: > Wenn du weniger als 1ms brauchst "Brauchen" ist relativ. Mir geht's um eine Optimierung der Responsezeit, weil jede Millisekunde, die ich nicht "auf der Strecke" verliere, muss ich nicht mehr aus meiner Anwendung rausquetschen oder kann einfach schneller werden.
Gast
#4223092
Pepe schrieb: > Einen ziemlich großen Teil der Aufgaben haben wir schon im > Mikrocontroller, aber es bleiben dummerweise noch einige Punkte, die > nicht dort laufen können. Da z.B. auf dem PC noch ne Bildverarbeitung > läuft und wir live auf die Ergebnisse reagieren müssen, können die > Mikrocontroller nicht vollständig autark laufen. Du kannst weder unter einen normalen Windows oder Linux Reaktionszeiten von 1ms erwarten. Wenn ihr das aber für eure Aufgabe braucht, dann sollte ihr gleich auf Echtzeitsystem setzen oder das Konzept ändern. Eventuell gibt es ein paar Tricks um das irgendwie zu schaffen, aber eine Garantie das es immer funktioniert wird wohl niemand für die Produktion geben können. Antwort schreiben |
Anzeige
|
