Moin Leutz, kennt sich jemand mit WinSock aus? Ich habe einen µC, der per ETH Daten gestreamt bekommt. Das muss ziemlich knackig & in Echtzeit laufen. Getestet ist das ganze unter Win7 bzw. Win8, mit verkabeltem ETH. Nun ist mir aufgefallen, dass der PC scheinbar die Antworten des µC (wenige Byte ACK/NAK) stark delayed, und der PC somit nix neues senden kann. Noch interessanter ist aber, dass die Übertragung flutscht wie Sau, wenn ich google Chrome öffne oder WoW Matrix (mit dem IE funzt das nicht), auch ohne, dass Daten übertragen werden. Diese Programme scheinen den ETH irgendwie umzukonfigurieren... Weiss jemand, wie man den WinSock mit weiteren Optionen konfigurieren kann (habe bereits RX/TX bufsize geseztz), so dass die Übertragung in jedem Fall schnell läuft? Werde da nicht so richtig fündig... Auffällig (s. pic) ist, dass das Delay zwischen den kurzen Daten-bursts 40ms beträgt, davon bekomme ich 8ms Daten. VG, /th.
Angehängte Dateien:
-
WinSockProb.png
24 KB
Random ... schrieb: > Nun ist mir aufgefallen, dass der PC scheinbar die Antworten des µC > (wenige Byte ACK/NAK) stark delayed, und der PC somit nix neues senden > kann. sicher? Es ist eigentlich andersrum. Der PC sammelt erst ein paar Daten bis er sie sendet. Damit verhindert man das jedes Byte in ein eigenen Packet gepackt wird. Um das Verhalten umzuschalten, kann man den socket auf TCP_NODELAY schalten.
Hi,
danke für die Antwort.
> kann man den socket auf TCP_NODELAY
ich vergass, die Übertragung läuft mit UDP :-)
Da finde ich diese Option nicht ...
Dass der PC die Daten erst sammelt kann auch sein, da ich immer nur max
4x 1kByte übertrage, und dann die Quittierung vom µC abwarte.
Random ... schrieb: > ich vergass, die Übertragung läuft mit UDP :-) und warum vergleichst du das dann mit Google Chrome? Nutzt der bei dir auch UDP?
genau das ist ja das merkwürdige. Das Bild oben zeigt, dass meine UDP Übertragung gas gibt, wenn ich google chrome starte. Beende ich chrome, fällt die Übertragung wieder zurück. Das ist kein Seiteneffekt von irgendwas anderem, das kann ich auch nach PC Neustart reproduzieren. Läuft chrome nicht, fällt der UDP in den 40ms Takt zurück.
dann finde erst mal raus ob es am Senden oder empfangen liegt. Wird ein packet sofort gesendet wenn du es willst? Wird es sofort empfangen? Vergleich mit Wireshark. Welche Zeit vergeht zwischen Empfangen und Senden?
Angehängte Dateien:
-
UDP_ok.png
18 KB -
UDP_nok.png
19 KB
Mit Wireshark bin ich gerade am messen, allerdings finde ich die Zeiten in Winsock nciht wieder. In der Grafik sieht man das UDP send sowie das rcv am µC.
Random ... schrieb: > Mit Wireshark bin ich gerade am messen, allerdings finde ich die Zeiten > in Winsock nciht wieder. du musst in deinen Programm selber die Zeit messen. Ist das Programm von dir selber geschrieben?
Beide Seiten sind unter meiner Kontrolle. Die Firmware auf dem µC ist von mir, die PC Seite (dll) macht ein Kumpel von mir, den src habe ich auch. Wenn man in die kurzen Peaks reinmisst, sieht man, dass das UDP Send den µC 3.44µs nach dem Empfang eines Datenpaketes verlässt. Die Diagramme kommen direkt von Variablen aus der Software (Cortex-M3 DWT, ULINK pro).
Random ... schrieb: > Wenn man in die kurzen Peaks reinmisst, sieht man, dass das UDP Send den > µC 3.44µs nach dem Empfang eines Datenpaketes verlässt. dann müsstest du das Packet ja im Wireshark auch kurz danach sehen. Dort steht ja auch die Systemzeit mit da. Dann müsstest du jetzt nur noch mit dem Zeitpunkt vergleichen wann du das Packet in deiner Software erhalten hast.
Das gleiche Delay in Wireshark beträgt 9.6ms
kannst du denn die 40ms in Verzögerung im Wireshark nachvollziehen?
Angehängte Dateien:
-
Wireshark.png
4,3 KB
Ja. Der µC (.43) sendet rq, der PC antwortet. Dann fragt der µC 2x nach knapp 10ms nach, dann kommen zwei ID requests (635, 636), dann fragt der µC bei 0.0184 noch mal nach, und der PC antwortet nach 0.019. Die 40ms scheinen 4 pakete a' 1kByte alle 10ms zu sein. Der Datenempfang selbst dauert 156µS im µC, nach 3.7µs wird bereits der ack gesendet, so dass der PC die nächsten Daten auf die Reise schicken kann.
Random ... schrieb: > Dann fragt der µC 2x nach > knapp 10ms nach, dann kommen zwei ID requests irgendwie kann ich nicht folgen. Es scheint doch so als ob der PC sofort antwortet. Warum kommen dann 2 Pakete vom µC?
Angehängte Dateien:
-
Wireshark.png
5,7 KB
Zwei Pakete kann sein, wenn sich der Timeout Task und der UDP send aus dem RCV sehr knapp überschneiden. Das ist aber nciht das Problem, denn der PC ignoriert double ACK. Screenshot dumm getroffen, hab noch mal drübergeschaut und das passiert sehr selten.
Angehängte Dateien:
-
UDP_ok2.png
3,7 KB
Starte ich Chrome, dann bekomme ich Daten in 1ms Abständen, solange ich anfordere. Ich gehe davon aus, dass man dem UDP Socket noch irgendeine Einstellung mitgeben muss, dass die Daten nicht gepuffert werden ... nur, was?
ich kann immer noch nicht so recht folgen. Ich kann nicht mal erkennen wo die Zeit vergeht. Ich kenne ja nicht den Inhalt und den ablauf der Übertragung. Ich kenne zumindest keine Option die man in der WinSock umschalten kann damit etwas schneller geht. Kannst du denn in deiner Software sicherstellen das die Antwort sofort versendet wird? Im besten wirklich mal die Zeitpunkte vom Empfangen und Senden mit locken. Dann könnte man es mit dein Zeiten im Wireshark vergleichen um festzustellen ob das Packet zu lange im "socket" festhängt. bin erstmal weg für heute...
Vermutlich ruft Chrome timeBeginPeriod() auf und der Thread kommt dadurch einfach schneller wieder zum Zuge.
Das hiesse ja, dass sich sämtliche Windows Timings ändern?
Bernd H. schrieb: > ermutlich ruft Chrome timeBeginPeriod() auf und der Thread kommt > dadurch einfach schneller wieder zum Zuge. kann ich mir zwar nicht vorstellen, das das solche extremen auswirkungen hat. Aber das sollte beim mitloggen der Sende und Empfangszeiten festellen können.
Hi, die Anahme war korrekt, der Wert für den Current Timer Interval ändert sich mit dem Starten von google Chrome von 15.6ms (maximum) auf 1ms (0.5ms ist minimum). Oha :-) Sollte man selbst auch sowas machen oder besser lassen?
Random ... schrieb: > Sollte man selbst auch sowas machen oder besser lassen? ich würde lieber nach der ursache in deinem quellcode suchen. Das verhalten kann durch aus ein zusammenspiel von ungünstigen Threadverhalten sein. MS schreibt dazu: Windows uses the lowest value (that is, highest resolution) requested by any process. Setting a higher resolution can improve the accuracy of time-out intervals in wait functions. hast du denn wartezeiten in deinen Code? Oder kommt es dann überhaupt zu einem timeout?
Nachtrag: ich lese das os: wenn man ein sleep(1) macht, dann dauert es ohne änderung z.b. 15ms und mit umschaltung des Timers wirklich nur 1ms. Aber welchen grund gibt es für ein Sleep?
timeBeginPeriod() wird z.B. hier drin erwähnt: http://msdn.microsoft.com/en-us/windows/hardware/gg463266.aspx "Modern processors and chipsets, particularly in portable platforms, use the idle time between system timer intervals to reduce system power consumption. Various processor and chipset components are placed into low-power idle states between timer intervals. However, these low-power idle states are often ineffective at lowering system power consumption when the system timer interval is less than the default. If the system timer interval is decreased to less than the default, including when an application calls timeBeginPeriod with a resolution of 1 ms, the low-power idle states are ineffective at reducing system power consumption and system battery life suffers." [..] "System battery life can be reduced as much as 25 percent, depending on the hardware platform." ...mit anderen Worten: Man verschwendet Energie.
Bernd H. schrieb: > ...mit anderen Worten: Man verschwendet Energie. damit halte ich das verhalten von Chrome schon als sehr bedenklich. Sie nehmen recht wenig rücksicht auf andere dinge, hautsache man bekommt seine Daten 10ms schneller. Wieder ein Grund Chrom nicht zu verwenden.
Ho, Sleep() verwenden wir mWn nicht, aber es sind waits drin, die auf Eth Daten warten (also die ACKs/NAKs vom µC). Die Daten werden von einer höheren Schicht entgegengenommen und für den Versand fertiggemacht. Dann werden als erstes 4 Pakete auf einmal, danach bis zum Datenende 1-4 Pakete "gleichzeitig" übertragen, abhängig von den ACKs/NAKs (es könnte ein Paket verloren gegangen sein...) Sollte das ETH wait for packet von diesem Timer abhängig sein, hätten wir da den Salat :-)
Random ... schrieb: > aber es sind waits drin, die auf Eth > Daten warten (also die ACKs/NAKs vom µC) Warten auf E/A dürfte vermutlich einen ähnlichen Effekt wie Sleep() haben und könnte tatsächlich die Ursache sein.
Bernd H. schrieb: > Warten auf E/A dürfte vermutlich einen ähnlichen Effekt wie Sleep() > haben und könnte tatsächlich die Ursache sein. nein, weil das ja ein warten auf ein Event ist und nicht auf einen Timeout. Events werden ja wohl nicht in den gleichen Zeitschleifen wie Timeout behandelt. So etwas währe mir schon aufgefallen, dann dürften ja Server-Sockets keine Antwortzeiten unter 10ms liefern und das ist nicht der fall. Ist der Code wirklich so geheim das wir ihn nicht sehen dürfen?
Hmm, das stimmt wohl. Dann ziehe ich meine Aussage zurück ;D
Hi, danke für die ganzen Antworten, die Sache mit dem Timer auf 1ms (scheint der default bei den meissten Windosen zu sein, vgl. Clockres) hats dann erstmal gebracht. Da es sich bei einem Wait for Event ja nicht um eine Timeslice im eigentlichen Sinne handelt, werden wir das Threading nochmal überprüfen, ob sich da nciht der Fehlerteufel eingeschlichen hat :-) VG, /th.
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.