LwIP Sockets API vs. Raw API vs. uIP Stack

Zu µIP kann ich was sagen.

µIp unterstützt keine Window Size. Daher muss der Empfänger jedes 
einzelne Datenpaket mit einem ACK bestätigen. Erst danach sendet µIP das 
nächste Datenpaket.

Daher musst du für jedes einzelne Datenpaket die komplette Round-Trip 
Zeit einplanen. Wenn die Verbindung Beispielsweise übers öffentliche 
Internet geht, wo zweistellige Millisekunden normal sind, reduziert sich 
die effektive Datenrate entsprechend. In diesen Fall lohnt es sich sehr, 
möglichst große Datenpakete zu senden.

Das Zusammenspiel mit Windows ist bei µIP besonders schlecht, denn 
Windows geht einfach davon aus, dass jeder andere Rechner eine gewisse 
Windows-Size unterstützt. Windows verzögert die ACK's um satte 200 
Millisekunden, un daran kann man nichts ändern. Will sagen, ein µC mit 
µIP kann zu einem Windows Rechner über das IP Protokoll nur 5 Pakete pro 
Sekunde mit je maximal 4kB übertragen. Bei UDP hast du das Problem 
nicht, denn die beantwortet Windows sofort.

Linux verzögert die NAK's auch, aber Linux merkt nach einer Weile, dass 
der Mikrocontroller nicht gut kooperiert und reduziert die Verzögerung 
nach einer Weile auf schätzungsweise eine Millisekunde.

Sowohl Linux als auch Windows Anwendungen können die Verzögerung über 
das Flag TCP_NO_DELAY deaktivieren. Telnet macht das so, die gängigen 
Web Browser leider nicht.

lwIP ist von dem gleichen Problem betroffen, wenn man dort Windows-Size 
1 hat. Mehr Window-Size erfordert allerdings auch mehr Pufferspecher - 
und zwar für jede gleichzeitige Verbindung. µIP braucht nur einen 
einzigen Puffer und kann darauf beliebig viele Verbindungen haben.

> 2) Ist die Performance des µIP Stacks vergleichbar mit der Raw-API
> des LwIP Stacks? (nach angepassten Buffer-Größen)

Da µIP designbedingt keine Window-Size >1 unterstützt, kann µIP nur 
gleich oder schlechter performen.

> µIP kann man auf sehr einfache Art beschleunigen, indem man jedes Paket
> zweimal unmittelbar hintereinander sendet. Dann kriegt man sofort ein
> ACK zurück, statt verzögert.

Als Seiteneffekt verdoppelt man damit allerdings auch die Auslastung des 
Netzwerkes.

Tassilo H. schrieb:
> Download-Rate von SD-Karte ca. 4 MByte/s. Ersetzt man die Dateizugriffe
> im FTP-Server (d.h. läßt man ihn zufaellige Buffer-Daten senden),
> erreicht der Download 10MByte/s, also mehr oder weniger die Grenze für
> 100MBit.
Das sind ja beeindruckende Raten. Zeigt mir dass bei mir noch viel im 
Argen liegt.

> Was mit bei der Implementierung aufgefallen ist:
> * Dem LwIP genug Speicher für pbufs geben (also so 10-20kB min.); ist
> man zu geizig wird es langsamer.
Nutzt du eigens definierte memory pools (MEM_USE_POOLS, 
MEMP_USE_CUSTOM_POOLS) oder die lwip Standards?
TCP_MSS hab ich auf 1460 (vom http server Beispiel von Atmel 
voreingestellt)
TCP_WND = 10 * TCP_MSS
TCP_SND_BUF = 10 * TCP_MSS
Damit sollte der Speicher ausreichend dimensioniert sein.

Hast du bei dir die Checksummen per Software erstellt und überprüft?

> * Der sendende Code sollte achtgeben, nicht solange mit tcp_write daten
> zu schicken, bis kein Speicher mehr für pbufs da ist, sondern selber
> mitzaehlen, wieviele Daten gerade unterwegs sind, und nur ein paar kB im
> voraus an den Stack geben. Das ist zumindes besser so wenn man mehr als
> eine TCP/IP-Verbindung bedienen will. Aber auch mit einer Verbindung
> sollte man nicht den kompletten Speicher füllen, sonst werden nacher
> noch ACK-Pakete gedropt.
das ist ein guter Hinweis, momentan sende ich am laufenden Band Daten 
raus, allerdings über nur 1 Verbindung.

Stefan Us schrieb:
>Das Zusammenspiel mit Windows ist bei µIP besonders schlecht, denn
>Windows geht einfach davon aus, dass jeder andere Rechner eine gewisse
>Windows-Size unterstützt. Windows verzögert die ACK's um satte 200
>Millisekunden, un daran kann man nichts ändern.
Tatsächlich ist der Empfänger (Server) eine Windows-Applikation. Wobei 
ich das TCP_NO_DELAY Flag hier setzen können sollte. Da ich nur eine 
Verbindung zwischen Client (µC) und Server (PC) habe, könnte µIP also 
vielleicht doch eine gute Wahl sein. Wobei die großen Datenmengen von µC 
zu PC gehen und umgekehrt nur Kommandos.

Um dem ganzen etwas Kontext zu geben, das soll als DAQ-Ausgangsbasis für 
unterschiedliche Projekte dienen.

> Tatsächlich ist der Empfänger (Server) eine Windows-Applikation.
> Wobei ich das TCP_NO_DELAY Flag hier setzen können sollte.
> Da ich nur eine Verbindung zwischen Client (µC) und Server (PC)
> habe, könnte µIP also vielleicht doch eine gute Wahl sein.

Ja. Wobei µIP nicht auf EINE Verbindung beschränkt ist. Die maximale 
Anzahl kannst du mit einer #define Zeile festlegen. Davon hängt der RAM 
Beadarf ab. Aber trotzdem teilen alle Verbindungen sich einen Puffer. 
Also hält sich das mit dem RAM Bedarf in Engen Grenzen.

Bei µIP muss der Application Layer jederzeit imstande sein, das letzte 
Paket zu wiederholen. Ich denke, dass ist der (neben der Window-Size) 
das auffälligste Manko an µIP. Ich nutze es trotzdem gerne.

Was beim Übertragen von Daten auf SD Karte besonders simpel ist, darauf 
hat man ja wahlfreien Zugriff.

danke für die Header. Da sich unsere Speichergrößen nicht groß 
unterscheiden nehme ich an dass die krasse Geschwindigkeitseinbuße von 
der Checksummenberechnung per Software kommt. Das wird beim LwIP Wiki ja 
auch als Geschwindigkeitsbremse Nr1 genannt.

Ist bei µIP ebenso.