Forum: Mikrocontroller und Digitale Elektronik lwIP Stack höhere Geschwindigkeit


von Anton F. (fogeltier)


Angehängte Dateien:

Lesenswert?

Hallo zusammen,
ich versuche nun schon seit geraumer Zeit meine lwIP Übertragungsrate zu 
erhöhen.
Dazu habe ich zunächst  wie in 
http://lwip.wikia.com/wiki/Maximizing_throughput beschrieben einige 
Einstellungen vorgenommen.
Die Ausschlaggebendsten davon sind:
1
/* TCP sender buffer space (bytes). */
2
#define TCP_SND_BUF             (16*TCP_MSS)
3
4
/* TCP sender buffer space (pbufs). This must be at least = 2 *
5
   TCP_SND_BUF/TCP_MSS for things to work. */
6
#define TCP_SND_QUEUELEN        (14 * TCP_SND_BUF)/TCP_MSS
Dadurch hab ich inzwischen eine Datenrate von knapp 50 Mbit/s erreichen 
können.

Damit ich ohne ein RTOS arbeiten kann, sende ich die Daten von meinem uC 
direkt an den Serverport, ohne einen Socket zu erstellen.
Eine Messung mit Wireshark hat ergeben, dass es  ca. 1,6 ms dauert bis 
der uC mit dem senden wieder anfängt, nachdem der Server ein Acknowledge 
geschickt hat.

Hat jemand von euch schon mal mit dieser Verzögerung zu tun gehabt bzw. 
das Problem gelöst? Oder hat jemand auf einem anderen Weg eine höhere 
Datenrate erreicht?

Ich verwende das Infineon Hexagon Application Kit mit einem XMC4500 uC 
ohne RTOS und einer 100Mbit Ethernetschnittstelle.

Im Anhang noch ein Auszug aus Wireshark

von Stefan F. (Gast)


Lesenswert?

> Dadurch hab ich inzwischen eine Datenrate von knapp 50 Mbit/s
> erreichen können.

Das wäre für einen 8bit Controller bei 20Mhz ungefähr das Maximum. 
leider ist die Berechnung der Prüfsummen aufwändig.

Dein Controller hat jedoch 32bit und 120Mhz, soweit ich das schnell 
herausgefunden habe. Da müsste es schneller gehen.

Was macht der Controller denn in dieser Zeit? Das solltest du mal 
herausfinden.

Vielleicht ist es einfach ein Messfehler. Windows braucht sicher auch 
seine Zeit, um ein Paket zu empfangen, zu prüfen und an Wireshark zu 
übergeben.

von gg (Gast)


Lesenswert?

Windows vergoessern

von Little B. (lil-b)


Lesenswert?

LOL, ich hab grad mal nachgerechet:

Der erste Burst, der im Screenshot zu sehen ist (paket 5481 bis 5488) 
ergibt eine Geschwindigkeit von 2,4Gbit !!!

RESPEKT!

Da muss ein Fehler in deiner Messung sein.
Objektiv betrachtet ist die Geschwindigkeit von 50Mbit gar nicht 
schlecht, vor allem da der lwIP gar nicht so "light weight" ist IMHO.

von Volker (Gast)


Lesenswert?

Könnte mit dem delayed Ack zu tun haben. Soweit ich weiß sendet IwIP, 
wie uIP auch, immer nur ein Paket und wartet dann auf die Bestätigung 
bevor er  dann das nächste sendet.
Dummerweise wartet der Empfänger ebenfalls eine gewisse Zeit bevor er 
die Bestätigung aussendet (damit er u.U. gleich mehrere Pakete auf 
einmal bestätigen kann).
Dieses Problem wird aber auch in der Doku irgendwo angesprochen.

von Little B. (lil-b)


Lesenswert?

Volker schrieb:
> Könnte mit dem delayed Ack zu tun haben. Soweit ich weiß sendet IwIP,
> wie uIP auch, immer nur ein Paket und wartet dann auf die Bestätigung
> bevor er  dann das nächste sendet.

Falsche Aussage, wie man am Wireshark-Ergebnis sieht.

Jedoch hab ich noch was anderes nachgerechnet:
Dein Controller schickt Bursts mit 11568 Byte Nutzdaten, der Inputbuffer 
von Windows hat aber 65070 Bytes zur Verfügung. Vieleicht kann daran 
noch gedreht werden, um die Häufigkeit des ACK zu verringern.

von Stefan F. (Gast)


Lesenswert?

Ach es sind 50Mbit!!!!
Ich habe (warum auch immer) 50kByte gelesen.

50Mbit schafft ein 20Mhz AVR natürlich nie und nimmer.

Also da hast du schon ein gutes Ergebnis. Mehr würde ich gar nicht 
erwarten eher weniger).

von Nosnibor (Gast)


Lesenswert?

Könnten die 1,6ms die round-trip-time sein?

Wenn der Wireshark auf demselben Rechner läuft wie der Datenempfänger, 
zeigt er für den Empfänger natürlich immer optimale Reaktionszeiten an 
(das ACK kommt 1...3µs nach dem PSH), während die Gegenseite schlechter 
ausieht, weil hier alle  Laufzeiten in Netzwerk, Ethernettreiber etc. 
dazugerechnet werden.

In dem Fall könnte es helfen, ein paar Pakete vorher schon ein PSH zu 
senden, um ein ACK zu provozieren, so daß der Sendepuffer nicht erst 
leer läuft.

Oh, ich sehe gerade, das passiert ja schon: der Sendepuffer ist 16 
Pakete groß, und nach je 8 Paketen kommt ein PSH. Dann ist es also 
tatsächlich ein lwIP-Problem. Konkret: warum hört lwIP nach dem PSH mit 
dem Senden auf? Hakt vielleicht die Kommunikation mit der Datenquelle?

Abgesehen davon sind 50Mbit TCP-Nutzdaten auf 100Mbit-Ethernet schon 
ganz ordentlich. Mehr als 80Mbit kann man sowieso nicht erwarten, auch 
wenn man mit viel Rückenwind und einer glücklichen Kombination von 
Netzwerktreiberversion und Switch-Firmware gelegentlich 90-95 beobachten 
kann.

von Anton F. (fogeltier)


Angehängte Dateien:

Lesenswert?

Hey,

vielen Dank für eure Antworten.

Zunächst mal die Aufnahme mit Wireshark war mit einem USB- 
Ethernetadapter. Bei dem ist es so wie es mir scheint, dass er die 
Packete zwischenbufferd und sie dann an Windwos weiterleitet. (Für Ping- 
Antworten braucht es immer um die 2ms, was auch recht lang ist). Daher 
auch die schnellen Bursts der 8 aufeinander folgendne Pakete.

Aktuell bekomme ich eine Übertragungsrate von etwa 58Mbit/s hin. Und 
zwar mit den Einstellungen
1
/* TCP sender buffer space (bytes). */
2
#define TCP_SND_BUF             (8*TCP_MSS)
3
4
/* TCP sender buffer space (pbufs). This must be at least = 2 *
5
   TCP_SND_BUF/TCP_MSS for things to work. */
6
#define TCP_SND_QUEUELEN        (8 * TCP_SND_BUF)/TCP_MSS

Was ich bisher nicht hatte war die Callbackfunktion nach erhalt eines 
ACK.
Die kann man mit der folgenden Funktion festlegen.
1
/**
2
 * Used to specify the function that should be called when TCP data
3
 * has been successfully delivered to the remote host.
4
 *
5
 * @param pcb tcp_pcb to set the sent callback
6
 * @param sent callback function to call for this pcb when data is successfully sent
7
 */ 
8
void
9
tcp_sent(struct tcp_pcb *pcb,
10
   err_t (* sent)(void *arg, struct tcp_pcb *tpcb, u16_t len))
11
{
12
  pcb->sent = sent;
13
}

Leider hab ich es nicht hinbekommen die Anzahl der Ack zu reduzieren. 
Was derzeit glaub ich die größte Bremse ist. Wie man im neuen 
Wiresharkauszug (interne Netzwekkarte) sieht, sende ich alle 6 Pakete 
ein "PSH,ACK". Damit habe ich versucht eben nur alle 6 Pakete ein ACK zu 
bekommen.

Naja, solangsam finde ich mich mit der Geschwindigkeit ab.

von avion23 (Gast)


Lesenswert?

USB 2.0 round trip time ist Minimum 2ms. Ohne Tricks Minimum 16ms. 
Üblich 64ms.

Bitte 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
Noch kein Account? Hier anmelden.