Author Topic: Massive "reset" Probleme nach Update auf Protokoll 2.0  (Read 10044 times)

remotecontrol

  • Hero Member
  • *****
  • Posts: 593
    • View Profile
Re: Massive "reset" Probleme nach Update auf Protokoll 2.0
« Reply #30 on: March 22, 2013, 12:24:09 »
Hab' nochmal was ausprobiert: Stack per USB+brickd am PC-1. Von anderem PC/Tablet per WLAN auf PC-1 verbunden: läuft relativ flüssig.
 
Direkt per WLAN gegen den Stack ruckt stark (jeweils ohne setResponseExpected). Also kann es eigentlich nicht am Betriebssystem liegen, das dort Pakete gebündelt werden. Völlig überlastet kann der Stack auch nicht sein, sonst würde es bei Anschluß über USB nicht so sauber laufen.

borg

  • Tinkerforge Staff
  • Administrator
  • Hero Member
  • *****
  • Posts: 3.142
    • View Profile
Re: Massive "reset" Probleme nach Update auf Protokoll 2.0
« Reply #31 on: March 22, 2013, 12:50:07 »
Also es ist definitiv so, dass die Daten zum Teil gebündelt bei der WIFI Extension ankommen, hier meine Debug Ausgabe:
Code: [Select]
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll
poll

[31, 9, 77, e4, b, 4, 50, 0, 0, fd, 2, poll
31, 9, 77, e4, b, 4, 60, 0, 5, 3, fd, poll
31, 9, 77, e4, b, 4, 70, 0, 1, 2a, 3, poll
31, 9, 77, e4, b, 4, 80, 0, 4, d6, fc, poll
31, 9, 77, e4, b, 4, 90, 0, 0, 2a, 3, poll
31, 9, 77, e4, b, 4, a0, 0, 5, d6, fc, poll
31, 9, 77, e4, b, 4, b0, 0, 1, 57, 3, poll
31, 9, 77, e4, b, 4, c0, 0, 4, a9, fc, poll
31, 9, 77, e4, b, 4, d0, 0, 0, 57, 3, poll
31, 9, 77, e4, b, 4, e0, 0, 5, a9, fc, poll
31, 9, 77, e4, b, 4, f0, 0, 1, 84, 3, poll
31, 9, 77, e4, b, 4, 10, 0, 4, 7c, fc, poll
31, 9, 77, e4, b, 4, 20, 0, 0, 84, 3, poll
31, 9, 77, e4, b, 4, 30, 0, 5, 7c, fc, ]
poll

Die "polls" sind im 1ms takt und wenn Daten da sind, werden sie mit ausgegeben. "[" und "]" geben ein einzelnes TCP/IP Paket an.

Da ist also eine ganz Zeit nichts und dann auf einmal kommt 14x setPosition.

Im Anhang das ganze nochmal in Wireshark. Dort sieht man die ganzen setPosition (die 77 Byte großen Pakete). Die gehen also eine ganz Zeit lang einzeln durch und dann auf einmal kommt ein Paket der Größe 209 wo die besagte Vielzahl an setPositions drin ist (siehst du auch unten im Payload, dort ist mehrfach 31 09 77..  drin).

D.h. die Pakete werden wirklich so vom Betriebssytem losgeschickt.

Jetzt muss ich dir allerdings recht geben: Wenn ich die Wi-Fi Strecke extern aufbaue von PC nach PC und dann über USB kommuniziere hab ich diesen Effekt nicht.

Die Frage ist also: Was macht die WIFI Extension, das dazu führt, dass das PC Betriebssystem mehrer Nachrichten in ein Paket zusammen schnürt?
Wir sind die Borg, Widerstand ist Spannung durch Stromstärke!

remotecontrol

  • Hero Member
  • *****
  • Posts: 593
    • View Profile
Re: Massive "reset" Probleme nach Update auf Protokoll 2.0
« Reply #32 on: March 22, 2013, 20:21:22 »
Bei mir redet der PC ja nichtmal direkt mit dem Stack, sondern per GBit Netzkabel mit der FritBox und die sendet die Pakete weg. Nur das Tablet kann direkt mit dem Stack kommunizieren. Umso komischer ist es, wenn das Betriebssystem hier was sammelt.

Ich werde mal einen tcpdump versuchen, den Stack auch als AP einrichten und damit testen, ob das einen Unterschied macht.

remotecontrol

  • Hero Member
  • *****
  • Posts: 593
    • View Profile
Re: Massive "reset" Probleme nach Update auf Protokoll 2.0
« Reply #33 on: March 22, 2013, 21:48:20 »
Der tcpdump der ersten Packages beim Aufbau des Sockets Tablet -> PC (ohne Ruckler) sieht so aus
Code: [Select]
21:23:08.345168 IP Nexus.47643 > mypc.4223: Flags [S], seq 4037415093, win 14600, options [mss 1460,sackOK,TS val 11923547 ecr 0,nop,wscale 6], length 0
21:23:08.345249 IP mypc.4223 > Nexus.47643: Flags [S.], seq 3885023147, ack 4037415094, win 14480, options [mss 1460,sackOK,TS val 54800367 ecr 11923547,nop,wscale 7], length 0
21:23:08.347537 IP Nexus.47643 > mypc.4223: Flags [.], ack 1, win 229, options [nop,nop,TS val 11923548 ecr 54800367], length 0
21:23:08.349080 IP Nexus.47643 > mypc.4223: Flags [P.], seq 1:9, ack 1, win 229, options [nop,nop,TS val 11923548 ecr 54800367], length 8

Und beim Aufbau des WLAN
Code: [Select]
21:03:55.527714 IP mypc.51853 > tinkertest.4223: Flags [S], seq 1809126939, win 14600, options [mss 1460,sackOK,TS val 53647549 ecr 0,nop,wscale 7], length 0
21:03:55.532842 IP tinkertest.4223 > mypc.51853: Flags [S.], seq 1301543003, ack 1809126940, win 2896, options [mss 1460,nop,wscale 0,nop,nop,TS val 676614046 ecr 53647549], length 0
21:03:55.532956 IP mypc.51853 > tinkertest.4223: Flags [.], ack 1, win 115, options [nop,nop,TS val 53647555 ecr 676614046], length 0
21:03:55.537074 IP mypc.51853 > tinkertest.4223: Flags [P.], seq 1:9, ack 1, win 115, options [nop,nop,TS val 53647559 ecr 676614046], length 8

Was auffällt ist, dass "SackOK" fehlt.
SackOK gehört bei dieser Art Verbindung eigentlich mit zum Handshake - oder?

borg

  • Tinkerforge Staff
  • Administrator
  • Hero Member
  • *****
  • Posts: 3.142
    • View Profile
Re: Massive "reset" Probleme nach Update auf Protokoll 2.0
« Reply #34 on: March 22, 2013, 22:15:48 »
Bei mir redet der PC ja nichtmal direkt mit dem Stack, sondern per GBit Netzkabel mit der FritBox und die sendet die Pakete weg.
Den Aufbau hab ich hier quasi auch: PC -> Gigabit Cisco Switch -> FritzBox -> Stack. Ich denke der Switch und der Router sind für die Probleme hier nicht relevant.

So wie ich das sehe passiert folgendes: Das WIFI Modul auf der WIFI Extension arbeitet mit delayed ACKs (http://en.wikipedia.org/wiki/TCP_delayed_acknowledgment). Ist in dem Screenshot auch zu sehen, dort gibt es ganz viele Nachrichten vom PC (77 Byte) und dann werden die alle mit einem ACK beantwortet. Nun scheint es aber so zu sein, dass der PC nach einer Zeit aufhört zu senden wenn er kein ACK bekommen hat. Das WIFI Modul sendet aber erst das delayed ACK wenn der Buffer voll ist (1500 Byte). Da gibt es ein Timeout von 200ms (d.h. wenn der Buffer nach 200ms nicht voll ist, sendet das WIFI Modul trotzdem das delayed ACK).

Da lagst du mit deinem "5hz ruckeln" schon sehr gut :).

Interessant ist jetzt: Wenn der Stack Nachrichten zum zurücksenden hat (damals die Reached Nachrichten vom Servo), dann wird das ACK auch schon frühzeitig zusammen mit diesen Nachrichten rausgeschickt. Daher gab es das 5hz ruckeln dort nicht.

Ich denke damit ist die Problematik ziemlich gut verstanden, es ist eine Mischung aus dem 200ms Timeout und der Anzahl der Nachrichten die das Betriebssystem schickt bevor es erstmal aufgibt wenn kein ACK kommt. Das Verhalten wird hier vermutlich von OS zu OS unterschiedlich sein.

Falls hier jemand weiß wie man sowas für gewöhnlich löst oder umgeht: Immer raus damit ;). Ich bin mir nicht sicher ob wir die 200ms Timeout  auf dem WIFI Modul verringern können. Dokumentiert ist da nichts, werde aber am Montag den Hersteller fragen.

Wir sind die Borg, Widerstand ist Spannung durch Stromstärke!

remotecontrol

  • Hero Member
  • *****
  • Posts: 593
    • View Profile
Re: Massive "reset" Probleme nach Update auf Protokoll 2.0
« Reply #35 on: March 23, 2013, 10:19:35 »
Das erklärt auch, warum es Ruckler in Kombination mit dem Quad-Relais gibt: wenn die Servo-Response aktiv ist, aber beim Relais nicht, führt der Monoflop-Impuls ohne Response zu einem 200ms Delay in der Netzwerkkommunikation.

Wenn ich für alle Befehle eine Response aktiviere, läuft es relativ flüssig :).

Falls sich am Netzwerkverhalten nichts mehr ändern lässt, wäre ein 3. Zustand beim Handling von 'responseExpected' denkbar (eher kleine Optimierung):
  • Nicht nur responseExpected true/false, sondern auch eine Art 'emptyResponse'
  • Bei 'emptyResponse' kehrt Device.sendRequest zurück, ohne auf die Response zu warten.
  • Der ReceiveThread wirft Responses dieser Art direkt weg

AuronX

  • Hero Member
  • *****
  • Posts: 877
  • kann Software, keine Hardware ^^
    • View Profile
Re: Massive "reset" Probleme nach Update auf Protokoll 2.0
« Reply #36 on: March 26, 2013, 19:42:51 »
Wow... interessant das zu lesen :D

Zum delayed ACK habe ich erstmal nur das einschlägige RFC (1122) bemüht:
Quote from: RFC1122
A TCP SHOULD implement a delayed ACK, but an ACK should not
be excessively delayed; in particular, the delay MUST be
less than 0.5 seconds, and in a stream of full-sized
segments there SHOULD be an ACK for at least every second
segment.

Möglicherweise könnt ihr bei eurem Chip ja nicht nur am Timeout sondern auch am Zähler stellen? Also sowas wie "ACK auf jedes 3. Packet"?

ArcaneDraconum

  • Sr. Member
  • ****
  • Posts: 453
  • Der Willis und ich haben den gleichen Frisör...
    • View Profile
Re: Massive "reset" Probleme nach Update auf Protokoll 2.0
« Reply #37 on: March 27, 2013, 15:46:40 »
Wenn ich das Ganze hier so lese.... Wie ist Euere Ethernet-Extension so aufgebaut? Kann es da ähnliche Effekte geben.

Sorry ist etwas OT, aber ich denke es gehört doch dazu.

borg

  • Tinkerforge Staff
  • Administrator
  • Hero Member
  • *****
  • Posts: 3.142
    • View Profile
Re: Massive "reset" Probleme nach Update auf Protokoll 2.0
« Reply #38 on: March 27, 2013, 17:50:09 »
Die Ethernet Extension wird absolut stabil sein. Dort wird es keinerlei Verbindungsprobleme geben, versprochen :). Wir testen da jetzt schon seit Monaten dran rum um das sicherzustellen.

Das hier angesprochene delayed ACK "Problem" gibt es bei der Ethernet Extension auch nicht, dort kann man delayed ACKs nämlich ausstellen ;).
Wir sind die Borg, Widerstand ist Spannung durch Stromstärke!

remotecontrol

  • Hero Member
  • *****
  • Posts: 593
    • View Profile
Re: Massive "reset" Probleme nach Update auf Protokoll 2.0
« Reply #39 on: March 27, 2013, 19:58:37 »
Noch eine Frage:
kann ich dem Kommentar jetzt entnehmen, dass die Anfrage beim Hersteller ergeben hat, dass sich der delayed ACK nicht abstellen lässt?

Dann muss ich mir nämlich noch was überlegen, um den Durchsatz noch etwas zu erhöhen/optimieren. Aktuell liege ich bei ca. 80 Requests Sekunde (eben mit Response). Was nicht mehr viel ist, verglichen mit 1ms über USB.

... und eine Anregung:
wäre ein "ErrorCallback" oder Ähnliches in der API für Euch nicht hilfreich? Ich habe im WLAN Code so ein paar TODO gesehen für Fehlerbehandlung, wo sich auch die Frage stellt: was ist überhaupt eine sinnvolle Fehlerbehandlung. Wenn der Client wenigstens einen Callback mit einem Fehlercode bekäme, würde das oft helfen, Probleme zu analysieren. Bei der LAN Extension ist der Durchsatz potentiel viel höher. Da könnten Puffer noch schneller voll sein.

borg

  • Tinkerforge Staff
  • Administrator
  • Hero Member
  • *****
  • Posts: 3.142
    • View Profile
Re: Massive "reset" Probleme nach Update auf Protokoll 2.0
« Reply #40 on: March 27, 2013, 22:04:31 »
Noch eine Frage:
kann ich dem Kommentar jetzt entnehmen, dass die Anfrage beim Hersteller ergeben hat, dass sich der delayed ACK nicht abstellen lässt?
Wir haben noch keine Antwort, die Mühlen mahlen da bei sowas leider langsam :(.

Dann muss ich mir nämlich noch was überlegen, um den Durchsatz noch etwas zu erhöhen/optimieren. Aktuell liege ich bei ca. 80 Requests Sekunde (eben mit Response). Was nicht mehr viel ist, verglichen mit 1ms über USB.
Wir sind noch dran, es gibt zumindest die Möglichkeit das wir händisch eine leere Nachricht rausschicken, wenn nach kurzer Zeit einer Anfrage keine Antwort rausgeht.

Also immer wenn eine Nachricht reinkommt wird ein 10ms Timer gestartet. Wenn eine Nachricht rausgeht wird dieser Timer gestoppt (mit der rausgehenden Nachricht wird ja auch ein ACK geschickt). Falls der Timer bei 0 ankommt schicken wir eine Dummy-Nachricht raus, um ein das ACK zu erzwingen. Damit wären dann in deinem Fall die 200ms Wartezeit auf 10ms verringert worden, dafür werden aber "unnötige" Daten geschickt (aber halt auch nur wenn sowieso keine Daten rausgehen).

Bei der LAN Extension ist der Durchsatz potentiel viel höher. Da könnten Puffer noch schneller voll sein.
Das IC was wir für die Ethernet Extension verwenden ist sehr low-level verglichen mit dem WIFI Modul. Dadurch gibt es diese Probleme gar nicht (wir haben das sozusagen selbst in der Hand). Da können keine Buffer voll laufen, da dem PC die Größe des Buffers mit der TCP window size mitgeteilt wird, wie es gedacht ist. Das hat natürlich auch nachteile, ich musste z.B. für die Ethernet Extension selbst einen DHCP Client implementieren, das war ganz schön aufwendig.

Bei dem WIFI Modul ist die API einfach beschissen. Es ist so, dass mit jedem Byte was wir rausschicken wir auch gleichzeitig eins empfangen. Da kann man nichts gegen machen. Wenn jetzt viele Nachrichten intern generiert werden (z.B. die Reached Callbacks vom Servo) und wir so viele Daten von extern bekommen, das in jeder ms neue Daten zum auslesen da sind, dann brauchen wir die Buffer.

In dem Fall ist es nämlich so, das wir z.B. 20 ausgehende Bytes generieren, die eingehenden Paket haben aber nur die Größe 10. Nun können wir aber nur ein Paket gleichzeitig behandeln, d.h. wir müssen 10 Byte Buffern damit wir das 20 Byte Paket überhaupt rausschicken können. Wenn der Buffer voll läuft müssen wir anfangen die ausgehenden Pakete wegzuwerfen. Total bekloppt :o.

Aber das hat nichts mit dem delayed ACK zu tun, wodurch du im Moment diese 5hz siehst.
Wir sind die Borg, Widerstand ist Spannung durch Stromstärke!

AuronX

  • Hero Member
  • *****
  • Posts: 877
  • kann Software, keine Hardware ^^
    • View Profile
Re: Massive "reset" Probleme nach Update auf Protokoll 2.0
« Reply #41 on: March 28, 2013, 10:54:54 »
ich musste z.B. für die Ethernet Extension selbst einen DHCP Client implementieren, das war ganz schön aufwendig.

Ich sehe IPv6 in der Unendlichkeit verschwinden ^^

borg

  • Tinkerforge Staff
  • Administrator
  • Hero Member
  • *****
  • Posts: 3.142
    • View Profile
Re: Massive "reset" Probleme nach Update auf Protokoll 2.0
« Reply #42 on: April 03, 2013, 19:33:21 »
Was ein Krampf ;D.

Also GainSpan konnte uns da nicht wirklich weiterhelfen. Es gibt undokumentierte Möglichkeiten an den Timeouts rumzustellen, allerdings wurde dadurch die Firmware instabil. Wir hatten ständig disassociation Events.

Ich habe jetzt einen 10ms Timer eingebaut der bei eingehenden Nachrichten (neu-)gestartet wird. Eine ausgehende Nachricht stoppt den Timer. Wenn der Timer bei 0 ankommt, wird eine Dummy Nachricht rausgeschickt die das Zurücksenden eines ACKs erzwingt. Dadurch ist aus deinem 5Hz Ruckeln jetzt ein "100Hz Ruckeln" geworden. Rein akustisch klingt ein Servo mit deinem Programm jetzt genauso wie wenn es über USB betrieben wird.

Wenn es zwischendurch Ruckler gibt kommen die durch TCP/IP retransmits. Das kannst du sehr schön in Wireshark sehen, immer wenn es ruckelt laufen in Wireshark rote spalten (retransmit oder duplizierte Nachricht) durch. Dagegen können wir natürlich nichts machen, die Daten gehen nunmal über die Luftschnittstelle. Da geht schonmal was verloren und muss neu geschickt werden ;).

Im Anhang ist eine beta der neuen Master Firmware.
Wir sind die Borg, Widerstand ist Spannung durch Stromstärke!

remotecontrol

  • Hero Member
  • *****
  • Posts: 593
    • View Profile
Re: Massive "reset" Probleme nach Update auf Protokoll 2.0
« Reply #43 on: April 03, 2013, 20:05:02 »
Ich teste das mal an wie sich das bei der WIFI Extension als AP verhält.

Ein "100Hz Ruckeln" ist ja schon kein merkliches Ruckeln mehr und für mich völlig ausreichend, mehr als erwartet.

AuronX

  • Hero Member
  • *****
  • Posts: 877
  • kann Software, keine Hardware ^^
    • View Profile
Re: Massive "reset" Probleme nach Update auf Protokoll 2.0
« Reply #44 on: April 04, 2013, 09:47:48 »
Idealerweise sollte das jetzt gar kein ruckeln mehr sein oder? Weil ein paar Millisekunden sollte sich das OS des PC ja nicht davon stören lassen, dass es kein ACK gibt.