Hallo, meine Windows-Software kommuniziert per UDP mit meinem Mikrocontroller. PC sendet ein Paket, Schaltung antwortet mit einem Acknowledge. Üblicherweise kommt die Antwort innerhalb <1ms, das sehe ich im Sniffer (Wireshark) und wenn ich die Laufzeit mit den mehr oder weniger genauen Windows Timerroutinen messe. Manchmal kommt die Antwort aber erst nach langer Verzögerung an, bis zu 60ms habe ich gemessen (wieder sowohl mit Sniffer als auch Timer). Durch messen von Debug-Pins an meiner Schaltung sehe ich aber, dass der Microcontroller die Antwort immer sofort (also <1ms) raussendet. Die Verzögerung entsteht im Windows Rechner. Das Problem tritt dann auf, wenn ich am Rechner die USB-TV-Karte laufen habe. Mit einem Task Analysator habe ich mal gekuckt was die TV Software macht, viel ist nicht zu sehen, sie verwendet die quartz.dll und directsnd.dll. Keine Ahnung ob die das Echtzeitverhalten verändern. Meine Anwendung setze ich auf Realtime Priorität. Die OS Timergenauigkeit setze ich mittels der Multimedia API timeBeginPeriod() auf 1ms, um nicht die Windows-typische 16ms Ungenauigkeit zu haben. Ich arbeite mit den althergebrachten Funktionen send(), select(), recv(). Nun habe ich gelesen, dass es unter Windows Overlapped IO Funktionen gibt, welche performanter sind und für Server mit vielen Verbindungen empfohlen werden. Eigentlich passiert ja nicht viel in meiner Anwendung, ich möchte nur auf einem Port Daten senden und möglichst schnell die Bestätigung. Es geht also um die Latenz, nicht Datendurchsatz. Weiss jemand ob die overlapped IO besser ist? Da mein Programm schon recht komplex ist möchte ich es nur ungern auf gut Glück umbaun. Danke Ignaz
Warum benutzt du eigentlich UDP? Dir sind die Schwächen von UDP bekannt? Deine Anwendung muss bei UDP deutlich aufwändiger sein, als bei TCP. Stichwort: verlorene Pakete, Reihenfolge. Falls du ein größeres Netzwerk hast könnte der Grund sein, daß du nie weisst welchen Weg UDP Pakete nehmen. Der Weg kann sich von einem zum anderen Paket ändern, mit den genannten Auswirkungen. Falls du das nicht schon alles bedacht hat lese dir doch mal den Wikipedia Artikel zu UDP durch. Ich kenne fast keine Anwendungen wo UDP TCP vorzuziehen wäre.
Udo Schmitt schrieb: > Ich kenne fast keine Anwendungen wo UDP TCP vorzuziehen wäre. Ich schon. Und ich kenne auch Fälle, in denen TCP verwendet wurde, und exakt deshalb grosse Probleme entstanden. Die durch UDP nicht entstanden wären. Die intuitive Annahme, TCP wäre (fast) immer besser, die stimmt so pauschal nicht. Da muss der Einzelfall betrachtet werden.
Das Problem bei TCP sehe ich darin, da im Fehlerfall nicht nur ein Paket sondern im schlimmsten Fall das komplette Window wiederholt wird. OK bei UDP muss ich eben selber für eine Fehlerkorrektur sorgen. Aber die werde ich denn so aufbauen, da ich keine Pakete neu senden muss (Foward error coreection). @ Ignaz (Gast) Wie du sagt hast du schon die Timerticks und Prio "hochgesetzt", wie sieht es denn aus mit deinem virtuellen Speicher ?? Ist der abgeschaltet worden ? Overlapped IO auf Windows kenne ich jetzt nicht (Linux User/Hacker). Aber sowei ich das mal kurz hier http://msdn.microsoft.com/en-us/library/windows/desktop/ms686358%28v=vs.85%29.aspx gelesen habe, ist dies mit dem Linux async IO identisch. Async IO wird, wenn es unter Linux/glibc benutzt wird, in einem anderen Thread abgewickelt. Der Vorteil das Hauptprogramm kann in der anderen Zeit weiter arbeiten, muss aber öfters den Puffer prüfen ob die Daten angekommen sind. Unter
Hans Ulli Kroll schrieb: > Das Problem bei TCP sehe ich darin, da im Fehlerfall nicht nur ein Paket > sondern im schlimmsten Fall das komplette Window wiederholt wird. Bitte was? 1. Fehler kommen wohl eher selten vor. Zudem erledigen die Schichten darunter die meisten Dinge wie einfache Datenfehler ohne daß du einen Finger rühren musst. 2. Wenn fataler Fehler dann Verbindungsabbruch und dann setzt du halt ne neue auf. Bei UDP musst du alle Daten selbst überprüfen und im Fehlerfall weisst du eventuell gar nicht was jetzt falsch ist. Da musst du nicht nur ein "Window" -ich denke du meinst ein Datenpaket- widerholen, sondern alles! A. K. schrieb: > Die intuitive Annahme, TCP wäre (fast) immer besser, die stimmt so > pauschal nicht. Da muss der Einzelfall betrachtet werden. Außer DNS Anfragen und vieleicht noch video/streaming fällt mir nicht viel ein. Zumindest nicht wenn ich mich auf die Daten und die Zeiten verlassen will. Aber du darfst mir gerne weitere Beispiele nennen, ich habe nicht gesagt UDP ist Scheiße, sondern daß in den meisten Fällen (und damit meine ich Kommunikation zwischen PC und µC) TCP die bessere und einfachere Wahl ist.
UDP ist immer dort passend wo das Verschwinden eines Packetes nicht so tragisch ist. Das sind ueblicherweise Streaming Daten. Video ist von der schnellen Sorte, es kann aber auch Sound oder auch nur Temperaturwerte sein.
Ich denke auch das hier UDP keinen Vorteil bringt, erst mal muss der TE jetzt das ACK selber machen, und scheinbar kann er nicht mal damit Leben das mal ein Paket einige ms später ankommt wie soll es erst werden wenn es tatsächlich mal verworfen wird? Aber ohne die Anwendung zu wissen natürlich schwer zu beurteilen, RealTime PRIO und OverlappedIO werden da aber wohl nicht weiterhelfen...
Udo Schmitt schrieb: > Außer DNS Anfragen und vieleicht noch video/streaming fällt mir nicht > viel ein. Zumindest nicht wenn ich mich auf die Daten und die Zeiten > verlassen will. Aber du darfst mir gerne weitere Beispiele nennen, (1) Messwertübertragung beispielsweise, wenn vorrangig der aktuelle Wert interessiert. Oder Steuerungen, die den letzten Stand herstellen wollen, statt den Schalter bei Problemen danach in schneller Folge klappern zu lassen. Generell alle Signalisierungen, bei denen der strenge zeitliche Ablauf per Datenstrom kontraproduktiv ist. Bei Steuerungen ist das nicht so selten. (2) Wenn der Übertragungsweg unterhalb von TCP/IP selbst bereits eine gesicherte Übertragung enthält, beispielsweise ein langsameres Funknetz, dann addieren sich die Retries von TCP zu den Retries des unteren Layers und können die Strecke verstopfen. Ich hatte den Fall einer solchen Übertragungsstrecke mit 3 Retransmission-Layern übereinander (einer drunter, einer drüber). Im Problemfall stapelten sich die Retries der oberen beiden Layer dermassen auf der Strecke, dass die danach unter permanenter Vollast lief und trotzdem aufgrund tiefer Queue aber begrenzter Bandbreite nur Timeouts produzierte, also ohne Reboot der ganzen Anlage nicht wieder in Tritt kam. (3) Ähnlich (2): TCP/IP wird als Trägerprotokoll von einer Anwendung verwendet, die auch mit anderen Übertragungsmedien arbeiten kann und einen eigenen Retransmission-Layer enthält. > (und damit meine ich Kommunikation zwischen PC und µC) TCP die bessere > und einfachere Wahl ist. TCP ist in vielen Fällen unstrittig einfacher. Und die Fälle (2) und (3) sind ganz bestimmte Situationen, die nicht unbedingt typisch sind. Aber es gibt einen gewissen Reflex, ohne darüber nachzudenken stets TCP zu verwenden. Der zu diese Fällen führte, in denen zwei Firmen Bockmist als Kommunikationslösung implementierten, der aber erst als solcher (von mir, nicht von denen) erkannt wurde, als das eine Zeitlang in Betrieb war, und aus den üblichen Gründen nur noch notdürftig geflickt aber nicht mehr revidiert werden konnte.
Hans Ulli Kroll schrieb: > Das Problem bei TCP sehe ich darin, da im Fehlerfall nicht nur ein Paket > sondern im schlimmsten Fall das komplette Window wiederholt wird. Schonmal was von SACK und Fast Retransmit gehört ?
Sauger schrieb: > eventuell haut dir dieser > > http://de.wikipedia.org/wiki/Nagle-Algorithmus > > dazwischen Ist für TCP, nicht für UDP.
Ignaz schrieb: > Das Problem tritt dann auf, > wenn ich am Rechner die USB-TV-Karte laufen habe Da wird der Treiber der TV-Karte einfach Scheiße sein, oder der Treiber der VGA-Karte.
Damals im Krieg schrieb: > Hans Ulli Kroll schrieb: >> Das Problem bei TCP sehe ich darin, da im Fehlerfall nicht nur ein Paket >> sondern im schlimmsten Fall das komplette Window wiederholt wird. > > Schonmal was von SACK und Fast Retransmit gehört ? Bevor ihr euch weiter auf die grossen Brüder konzentriert, solltet ihr vielleicht berücksichtigen, dass TCP/IP Stacks von einfachen Mikrocontrollern selten in voller Blüte stehen. Sie meistens nur Grundfunktionen implementieren. Was einerseits eher kleine Windows erzwingen kann (Speichermangel), notfalls zu Lasten des maximalen Durchsatzes. Was andererseits die Existenz weiter entwickelter Variationen eher unwahrscheinlich macht, zumindest beidseits gesehen.
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.