Ethernet: Wie kann ich die Antwortzeit verkürzen?

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?

@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.

Muss es Windows sein?
Man könnte ja auch mal ein kleines schlankes Linux probieren.

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.

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.

@ThomasF
Wie hast Du die Sende/Empfangsroutine unter Windows implementiert?
Scheint wohl bei mir das größte Problem zu sein.

@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)

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.

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.

Ich hab den Stream mal aufgezeichnet.
Im Wireshark sind es ca. 600µs (1.2ms ist der Durchschnitt)

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.

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.

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.