uIP + TCP: Problem mit #define UIP_CONF_BUFFER_SIZE

[Caspar B. (caspar)]

Hallo,

auf meinem LPC1769 läuft FreeRTOS mit dem uIP Stack. Ich mächte gerne 
viele Daten schnell vom PC zum lpc senden. Mit UDP klappt das auch ganz 
ausgezeichnet, mit guten 10 MByte/s. Wenn ich das ganze aber mit tcp 
mache, funktioniert das komischerweise nur, wenn die Puffergröße 
(#define UIP_CONF_BUFFER_SIZE) klein genug, also kleiner 500 ist. Falls 
sie größer ist, funkioniert nur das Übertragen kleiner (<300Byte) 
Datenmengen, annsonsten kommt Datenmüll an.

Hängt das vl mit der Zerstückelung der Pakete zusammen?

Hat das jmd schon mal gesehen und kann mir Tips geben?

VG

caspar

[Caspar B. (caspar)]

push

[Jürgen (jliegner)]

Beitrag "STM32F1xxx LwIP Datendurchsatz"

ist das das Problem?

[Caspar B. (caspar)]

Erstmal danke für die Antwort.

Ich denke nicht, da ja der Durchsatz über TCP, trotz des kleinen 
Puffers, so schlecht nicht ist (knapp 2 MegaByte/s). Aber der kleine 
Puffer beeinflußt vl die ausgehandelte Packetgröße. Ich verstehe halt 
einfach nicht was da los ist. Der Durchsatz wird auch besser für einen 
größeren Puffer, bis dann ab ca. 500 Byte irgendetwas schief läuft.

Ich würde halte gerne verstehen was passiert.

In der Tat sehe ich mit Wireshark aber auch während der gesamten 
Übertragung doppelte Acks, sowohl vom PC/Linux also auch vom lpc.

Ping liefert auch ein DUP! .

Vl sagt das jmd was, mir nicht. Das geht ja schon in Richtung dieser 
delayed acks.

UDP hingegen geht immer, mit jeder Puffergröße.

[JojoS (Gast)]

beim uIP gibt es diesen Workaround gegen das 'nagling', das 
Zusammenfassen kleiner Pakete aus Performancegründen. uIP sendet 
absichtlich alles doppelt um ein sofortiges ACK zu erzwingen. Ich finde 
diese Lösung nicht gut und das kann ein Grund für deine Fehlfunktion 
sein.
Der LPC1769 könnte auch automatisch mehrere Pakete puffern, aber der uIP 
Stack nutzt das offensichtlich nicht. Ich habe da auch eine Anzahl 
Buffer in den Quellen gefunden, aber benutzt wurde die nicht.

[Jürgen (jliegner)]

nicht nur uIp auch lwIp hat mit Windows Clients ein Problem wegen der 
delayed ACKs. Irgendjemand hat hier schon mal geschreiben, dass die 
WizNet Module auch alles doppelt schicken, da sie das selbe Problem 
haben. Das ist aber nur mit Windows eins. Linux hat damit keine 
Probleme.

[JojoS (Gast)]

die Beiträge aus dem angegebenen Link habe ich gerade gelesen, laufen ja 
auf das Gleiche hinaus.
Windows verhält sich aber nur regelkonform, den Algorithmus hat der Herr 
Nagle eingeführt und der war auch in vielen Unixen zu finden. Das 
doppelte oder gesplittete Senden ist natürlich ein einfacher Workaround, 
die CM3 Controller hätten aber genug Power für bessere Lösungen. Aber 
wer schreibts...

[Caspar B. (caspar)]

Ja, besonders schön scheint mir das auch nicht. Aber ist das wirklich 
der Grund für den Datenschrott wenn  UIP_CONF_BUFFER_SIZE > 500 ? Das 
scheint mir unwahrscheinlich ... Sonst (also für  UIP_CONF_BUFFER_SIZE < 
~500) funktioniert es ja tadellos, trotz der vielen dup acks.

Recht krass dass die WizNet Module auch doppelte acks nutzen, irgendwie 
wirkt das wie ein fieser workaround.

Im Grunde sollte der Puffer doch etwa 1500 Byte sein für optimale 
Performance. Und das ist halt nicht möglich bei mir.

[JojoS (Gast)]

ich habe die Beispiele für LPCXpresso angesehen, in RTOSDemo_RDB läuft 
ein WebServer und da ist UIP_CONF_BUFFER_SIZE = 1480. In 
EthDev_LPC17xx.h werden mehrere EMAC buffer mit 1536 max. Ethernet Frame 
size angelegt. Das Beispiel läuft, aber der Webserver wird auch nicht 
mit grossen Datenmengen bombardiert.
Dann folge doch mal der Datenspur im Debugger.

[Caspar B. (caspar)]

Hallo,

so, ich habe jetzt nochmal mit dem RTOS-Demo und auch ganz ohne RTOS 
probiert.

Zunächst einmal verschwinden die doppelten (dup) acks in der tcp 
Kommunikation beim Beispiel ohne Betriebssystem (RDB1768cmsis2_uIP), mit 
UIP_CONF_BUFFER_SIZE ~ 1500. Auch Ping sieht so aus wie es soll. Aber: 
Wenn ich sehr große Datenmengen schreibe und im LPC in einen Puffer 
speichere, verschwinden anscheinend einige wenige Packete. Wenn ich nur 
einige 10-100 Byte schicke, ist alles ok. Auch telnet usw. laufen 
fehlerfrei. Das Problem tritt erst auf, wenn ich viele Daten schnell 
sende. Die Netzwerkstatistikausgabe des Webservers zeigt keinerlei 
Fehler an. Das darf doch nicht sein, oder? TCP soll doch gerade 
garantiert die Daten liefern.

Also die Daten werden so empfangen:

if(uip_newdata())
{
    int len = uip_datalen();       
    strncpy(puffer,uip_appdata,len);
}

Den Puffer schaue ich mir dann z.B. über telnet an. Wenn ich jetzt eine 
feste Zahlenfolge vom PC sende, erscheint die für viele übertragene 
Daten verschoben im Puffer. Hm, vl liegt da auch der Fehler? Hmhm...

Und das Beispiel mit RTOS (RTOSDemo_RDB1769) zeigt schon out-of-the-box 
die doppelten Acks. Sehr sonderbar.


Na, ich such mal weiter. Tips und Hinweise sind willkommen!

VG

caspar