Hallo Leute, würde gerne eure Werte der LAN Übertragung erfahren, habe LwIP auf einem STM32F107 laufen und erreiche beim versenden von HTML Files (fsdata) aus dem internen Flash über http ca. 11Kb/s, das ist sehr mager. LAN ist im DMA Mode konfiguriert und in der main->while() Schleife wird nur geprüft, ob http Daten angekommen sind. Habe das Gefühl, als würde irgendwas den ganzen Verkehr ausbremsen. Wireshark kriege ich auf dem PC nicht zum laufen. Getestet habe ich mit dem tool DownTester.exe von nirsoft. Mit Webseiten wie yahoo etc. erziele ich ca 2Mb/s http downstream. Habe mir die LwIP Optimierungsmöglichkeiten durchgelesen, bringen tut es aber nichts.
Also mit LwIP kenne ich mich nicht aus aber uIP hat ein grosses Problem mit dem "TCP delayed acknowledgment", das unter Windows standardmässig eingeschaltet ist. Da gibts die wildesten Hacks um das zu umschiffen wie z.B. jedes Paket in 2 kleine zu teilen oder einfach jedes Paket doppelt zu senden. Da LwIP vom selben Autor kommt ist die Gefahr groß, dass es auch da so ist. Laut meinem Verständnis ist das so, wenn der Client (insbesondere Windows) ein TCP-Paket empfängt sendet er einfach noch kein ACK zurück sondern wartet erst mal 100ms oder mehr. Kommt kein weiteres Paket sendet er dann das ACK. Dadurch bricht die Kommunikation bei vielen kleinen Paketen total ein, da uIP erst dann das nächste Paket sendet wenn das ACK vom vorhergehenden gekommen ist. Sendet der Server 2 Pakete hintereinander, u.U. auch das selbe 2 mal, dann antwortet der Client sofort mit einem ACK und alles läuft wie am Schnürchen. Untersuche mal ob das bei dir die Ursache ist, denn dann musst du an einer völlig anderen Stelle suchen. Gerade wenn man mit einem Windows Web Browser auf den Server zugreift bringen die o.g. Hacks gefühlte Lichtjahre Verbesserung. Oder mal zum Testen einen Linux-Browser verwenden oder versuchen das "TCP delayed acknowledgment" unter Windows auszuschalten.
noch ein Nachtrag: im lwIP Wiki (http://lwip.wikia.com/wiki/Maximizing_throughput) steht ganz unten: Try to prevent sending small chunks of data waiting for an ACK: delayed ACK on the remote host might destroy performance (often, only every 2nd packet is ACKed) Das bestätigt meine Vermutung.
Konnte der Stack nicht per Option mehrere Pakete gleichzeitig versenden!?
Ein Problem kleiner Stacks besteht in der Tat darin, dass die Gegenstellen erst einen Timeout abwarten, bevor sie ein einzelnes Paket bestätigen. Allerdings hätte ich gedacht, dass LwIP darauf eingeht, das ist ja doch nicht ganz so minimalistisch wie das uIP mit seinem einzigen Puffer. Im uIP gibt es dazu eine Optimierung, die das Paket in zwei Teile splittet, aber damit war ich nicht glücklich geworden. Aus dem Tracing des Verhaltens eines Wiznet-Chips ergibt sich ein simpler Workaround (mit uIP ungetestet): Auf der Ebene des Adaptertreibers jedes Paket zweimal direkt hintereinander versenden. Das ergibt zwar doppelte Bandbreite in dieser Richtung, bringt aber die Gegenstelle dazu, das Paket pronto zu bestätigen.
genau das habe ich bei uIP auch gemacht. Das Splitten hatte ich auch erst probiert, aber nur mäßige Erfolge erzielt. Das verdoppeln wirkt Wunder, auch wenn's nicht ganz Regelkonform ist.
>lwIP Wiki (http://lwip.wikia.com/wiki/Maximizing_throughput)
Die Optionen habe ich mir angeschaut. Also so klein sind die Pakete
nicht. Die Files (Bilder, CSS, HTML) sind im Bereich von 1-4Kb. Die
letzten Pakete der jeweiligen Datei können natürlich kleiner ausfallen,
falls nicht der ganze Rahmen gesendet wird. Ich hab jetzt endlich hin
bekommen Wireshark zu installieren, werde mir die Zeiten angucken, wann
mein PC ein ACK zurücksendet, wobei wie gesagt, mit anderen Webseiten
klappt es ja wunderbar. Die sind von der Struktur ja ähnlich.
4k im Stück geht ja sowieso nicht wegen der MTU. Selbst wenn jedes Paket die MTU maximal nutzt und dann aber 100ms bis zum ACK vergehen, sind das pro Sec 10 Pakete. Dazu kommen dann noch die favicon.ico Abfrage bei jedem Request. Alles in allem ergibt das ein Verhalten so wie du es beschreibst.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.