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).
Thread beobachten
Seitenaufteilung abschalten