lwIP+FreeRTOS TCP Pakete manchmal übersprungen

Ahnungsloser Gast #5176565
Lesenswert?
• ▲
▼ 
Zur Illustration was passiert (Längen beziehen sich nur auf die 
Nutzdaten):
1
lwIP                                   Linux4.4

2
... (Normaler Traffic alternierend PSH, ACK ->; ACK <-)

3
 ---- D (L: 42 B, Seq: 909706)  ---------->

4
 <--- ACK (Seq: 909748) ------------------

5
 ---- D (L: 536 B, Seq: 909954) ---------->

6
 <--- ACK (Seq: 909748) ------------------

7
 ---- D (L: 536 B, Seq: 910490) ---------->

8
 <--- ACK (Seq: 909748) ------------------

9
... (Timeout, retransmit folgt:)

10
 ---- D (L: 536 B, Seq: 909748) ---------->

11
 <--- ACK (Seq: 911026) ------------------


Über einen lwIP TCP socket werden relativ kleine Pakete (~45B payload) 
mit 200Hz gesendet. Unregelmäßig, ca. alle 2 Minuten, werden einige 
"übersprungen" und ein Block nachfolgender Daten gesendet - bis nach dem 
Timeout der Retransmit der "übersprungenen" Daten kommt. Das macht das 
System für eine Echtzeitanwendung unbrauchbar.

Rahmenbedingungen: STM32F4 @ 180MHz mit FreeRTOS generiert von 
STM32CubeMX, Speichermanagement-Schema "heap_4". Benutzt wird die 
Socket-API von einem einzelnen Task. Die MSS wie in der "Grafik" oben 
sichbar is 536 B.
Die lwIP-Buffer sind sehr großzügig dimensioniert, ich konnte nach etwas 
spielen mit ihnen keinen Unterschied feststellen; sehr wohl aber wenn 
mehrere Verbindungen Daten senden, das Verhalten tritt dann deutlich 
häufiger auf.

Wäre für alle Hinweise dankbar, manchmal sieht man einfach den Wald vor 
lauter Bäumen nicht mehr...
Als nächsten Test würde ich das ganze nocheinmal mit einer anderen 
lwIP-API ausprobieren.
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
gedünsteter Doppeltroll Gast #5176596
Lesenswert?
• ▲
▼ 
> Echtzeitanwendung ..

Echtzeitanwendung bedeutet es wird auf ein Ereignis innerhalb einer 
gewissen Zeit geantwortet. Hier scheint's nicht.
Was soll denn uebertragen werden ? Sind die Daten redundant, oder nicht. 
Bei einem Audiostream sind die Daten redundant, bei einem Filetransfer 
nicht.

Wenn retries nicht akzeptierbar sind ...
- ist der Timeout zu lang ?
- wieviel Delay waere akzeptierbar ?

Allenfalls waere UDP mit Forward Error Corrcetion interessant.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
4328970765432459780876543 Gast #5176602
Lesenswert?
• ▲
▼ 
schau mal in die ethernet.c

ist das noch mit der semaphore in der sendefunktion ?

ich habe den ethernet Task statt semaphore mit der tasknotify genutzt
ebenso in der sendefunktion die semaphore entfern und dafür die 
chachefunktionen eingebaut
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Ahnungsloser Gast #5176650
Lesenswert?
• ▲
▼ 
Danke für die Antworten!
Klar könnte ich das Problem mit z.B. UDP einfach umgehen. Da das aber 
wie heute üblich eine 1-zu-1-Verbindung ist und damit Kollisionen 
ausgeschlossen werden können gibt es für mich keinen echten technischen 
Grund das zu machen.

Ich verwende die aktuellen STM32CubeMX-Versionen, d.h. lwIP 2.0.x, in 
der ethernet.c direkt gibt es keine Synchronisierungsstruktur.

Gibt es einen anderen Grund als sich ein paar Bytes RAM und ein paar 
Zyklen bei der Synchronisation zu sparen für deine Änderungen an lwIP, 
4328970765432459780876543?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Ahnungsloser Gast #5176730
Lesenswert?
• ▲
▼ 
Hardware kann ich mir ehrlichgesagt überhaupt nicht vorstellen...
Ist momentan noch ein STM32F4 144Pin-Nucleo-Board an einem PC, das 
Problem tritt an mehreren PCs auf. => Ganz klar auf der µC-Seite.
Ich hatte mit der Stabilität von lwIP (oder meiner Verwendung davon?) 
schon einmal Probleme... Bei Benutzung der Raw-API würde die 
Transferrate über Minuten-Stunden immer geringer. Das scheint mit der 
neuen lwIP-Version nicht mehr zu passieren (damals mit FreeRTOS+lwIP 
1.4.x, Senden aus dem Default Task, außer lwIP und RTOS-eigenen keine 
weiteren Tasks, keine dynamische Allokationen etc. in der eigenen 
Software).
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Ruediger A. (Firma: keine) #5176963
Lesenswert?
• ▲
▼ 
Wenn Du sagst "die lwip Buffer seien grosszügig dimensioniert" - meinst 
Du damit auch die Anzahl Rx DMA Deskriptoren im Ethernet Treiber?

Der zuverlässigste Weg herauszufinden, wo die Pakete verloren gehen ist 
durch mitzählen der Pakete im Kontrollfluss, d.h. auf jeder Ebene 
(Ethernettreiber, ip_input(), tcp_input() etc) mit jedem verarbeiteten 
Paket einen Zähler erhöhen. Wo ein Delta von -1 auftaucht, ist das Paket 
verloren (natürlich musst Du die Zahl auch gegen die im PCAP log 
gesehenen Pakete abgleichen).

Bekommst Du vom DMA Treiber Fehlermeldungen über vom PHY verworfene 
Pakete oder overflows der DMA Engine? Das Ganze kann auch mit der 
Prioritätensteuerung von lwip zu tun haben. Wenn die Task, die Pakete 
wegschaufelt, von einer Anderen Task ausgelockt wird, kann die DMA 
Engine einen Paket overflow generieren, d.h. Pakete verwerfen, die nicht 
mehr in den Ringbuffer passen. NB: Ob Du das tolerieren kannst oder 
nicht, ist eine Frage des Systemdesigns. In der Regel sagt man, dass 
Netzwerkaktivitäten auf low Pri laufen sollten (also low Priority 
Interrupthandler und low Priority Verarbeitungstask), weil die 
Netzwerklast in heterogenen und offenen Netzwerken nichtdeterministisch 
ist und damit ein Netzwerk mit hoher Last (z.B. mit Broadcaststürmen) 
die "richtige" Aufgabe des Systemes lahmlegen kann. Ist die 
Hostkommunikation im kritischen Pfad, hast Du mit Netzwerken per 
Definition ein nicht lösbares Problem und solltest auf eine 
deterministische Hostkommunikation ausweichen. Im Umkehrschluss musst Du 
adnn aber mit Paketverlusten leben.

Das ganze hat mit TCP oder UDP nicht das Geringste zu tun. Paketverluste 
sind erstmal legitim und werden durch den Sequenzierungs- und 
Retransmission Mechanismus kompensiert (das ist die Definition von TCP).
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren