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.
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.
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?
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.
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?
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.
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...
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?
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.
WinSockProb.png
(24 KB)
