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