Hallo Gemeinde, ich hatte mich in den letzten Tagen intensiver mit dem Datendurchsatz des ESP8266 befasst, speziell in Bezug auf die AT-Firmware. Da ich auf meinen ESPs zur Zeit nur die AT-Firmware und dafür eine AT Parser-Bibliothek verwende, wollte ich gerne mal wissen, wie der tatsächliche maximale Datendurchsatz mit der AT-Firmware aussieht. Ich habe schon vieles dazu im Bezug auf die direkte Programmierung über die Arduino-Plattform gelesen und darüber, dass Leute damit teils Übetragungsraten von einigen Mbit/s erreicht haben. Mir geht es hier aber vor allem um die maximal mögliche Rate mit der AT-Firmware und über die Möglichkeiten, die es so gibt oder die ihr kennt, um diese maximal werden zu lassen. Hierzu hatte ich bereits in diesem älteren Beitrag Beitrag "Re: ESP8266 UDP send performance" gelesen, dass wohl die schnellste Übertragung eines Pakets mit der AT-Firmware 100ms dauert (einfache Strecke). Dies deckt sich auch mit meinen Beobachtungen mittels Logic Analyzer bei meinen Arbeiten. Diese Beobachtung samt dem genannten Beitrag führte mich zu der Erkenntniss, dass man einfach mit der Erhöhung der Baudrate nicht weit kommt, da diese ja nur die Übertragung der Daten an den ESP etwas beschleunigt, die Paketumlaufzeit aber unverändert bleibt. Würde also die Baudrate theoretisch gegen Unendlich gehen, so würde die Dauer der seriellen Übertragung gegen 0 gehen und es blieben immer noch die ungefähren 200ms. Es wäre daher die Aufgabe, ebendiese Paketlaufzeit irgendwie zu verringern. Gibt es also von eurer Seite dazu vielleicht irgendwelche Messungen, Erkenntnisse oder konkreten Hinweise, ob und wie man diese Paketlaufzeit noch irgendwie drücken kann? Vielleicht gibt es ja irgendwelche AT-Befehle oder eine besonders günstige Auslegung der zu sendenden Daten, damit man mehr über die Luft kriegt? Im übrigen verwendet die Parser-Bibliothek AT+CIPSEND=x,y als Sendebefehl. Ich habe aktuell keine Möglichkeit, dies auf einen anderen Befehl wie vielleicht AT+CIPSENDBUF umzustellen. Aber soweit ich es in der Befehlsdokumentation gesehen habe, können diese Befehle alle ohnehin nur maximal 2048 Byte in einem Rutsch schlucken. Ich schicke also sowieso schon 2048 Byte mit AT+CIPSEND, um dort das meiste rauszuholen. Vielen Dank schon mal für eure Mühen und Anregungen. Besten Gruß
:
Bearbeitet durch User
Hat niemand eine Idee hierzu? Auch nicht die erfahrenen ESP-Nutzer?
:
Bearbeitet durch User
Deine Erkenntnisse kann ich nur bestätigen. Ändern kann man daran nichts, außer durch das Schreien einer eigenen Firmware (z.B. mit Arduino). Offensichtlich sammelt die AT Firmware Daten vom seriellen Port in einen Puffer und prüft ungefähr alle 100ms, ob darin etwas zum Senden steht.
Da hat man schon eine Rechtschreibkontrolle eingerichtet, und dann so was...
Gibt es die AT-Firmware irgendwo als Sourcecode?
Ich habe mal bei Github unter dem NONOS-SDK nachgesehen, wo auch die Binaries für die AT-Firmware erhältlich sind. Leider finde im ganzen Repository nicht wirklich viel Quellcode, außer vielen Header-Dateien. Ich vermute stark, dass die AT-Firmware sich in einer der bereits kompilierten Bibliotheken befindet (wahrscheinlich in der Datei <espat.a>). Oder hast du noch eine andere Quelle, an die ich jetzt nicht gedacht habe und wo man den Quellcode dazu rauskriegen könnte? Im übrigen habe ich gestern noch einen Beitrag in der ESP8266 Developer Zone zu dem Thema des Sende-Delays in der AT-Firmware gefunden: http://bbs.espressif.com/viewtopic.php?f=16&t=8348&p=18141#p18141 Die Beiträge sind auch noch recht frisch und vielleicht lässt sich da mit genügend Nachdruck von der Community ja noch eine Anpassung in der AT-Firmware bei Espressif erwirken. Denn die Asymmetrie beim Sendeverhalten, die der Poster dort beobachtet hat, ist mir auch schon aufgefallen. Wenn Daten beim ESP ankommen, so werden diese immer sofort durchgereicht. Ausgehende Daten (wohlgemerkt: kleiner Daten, die den Puffer des ESP nicht sofort füllen) werden immer in dem bereits bekannten 200 ms Raster versendet. Aber es kann ja z.B. bei einem Protokoll wie HTTP nicht Sinn der Sache sein, dass ein Client, der Daten vom ESP abruft, noch Dummy-Daten nach seinem Request hinterschickt, nur damit die Antwort des ESP schneller rausgeht. Das wäre ja auch wider jegliche Standards und überhaupt auch gar nicht realisierbar.
A.. P. schrieb: > Es wäre daher die Aufgabe, ebendiese Paketlaufzeit > irgendwie zu verringern. Vergiss es! Diese ist bei WLAN systemimmanent. Mit 200ms bist Du da noch gut bedient.
Andreas B. schrieb: > A.. P. schrieb: >> Es wäre daher die Aufgabe, ebendiese Paketlaufzeit >> irgendwie zu verringern. > > Vergiss es! Diese ist bei WLAN systemimmanent. Mit 200ms bist Du da noch > gut bedient. Das ist Schwachsinn und wieder nur eine andere Audrucksform von "Kabel ist immer besser". Und dass eben diese 200 ms nicht nur auf die Übertragungstechnik selbst zurückzuführen sind, ist mittlerweile hinlänglich bekannt. Wie wäre es sonst zu begründen, dass beim ESP eingehende Daten bei mir mit einer Übertragungsrate von ca. 25 KB/s eintrudeln, ausgehende Daten aber nur mit ca. 1/10 dieser Rate? Ich will damit nicht abstreiten, dass die Übertragung über die Luft i.d.R. langsamer ist, als über ein Kabel, aber speziell im Fall des ESP habe ich (und andere ja offensichtlich auch) schon mehrmals nachgemessen und immer wieder diese 200 ms Verzögerung in Senderichtung festgestellt. Und dass deine Behauptung, die 200 ms wären bei WLAN einfach systemimmanent, Unsinn ist, zeigt sich schon daran, dass ich z.B. mit Wireshark nachmessen kann, dass auf mein vom ESP versendetes TCP-Segment das ACK in weit unter 200 ms ankommt, der ESP aber dennoch bis zum Ablauf dieser Zeit wartet, bis von ihm das "SEND OK" zurückgemeldet wird. Und mit 200 ms Paketumlaufzeit soll ich gut bedient sein? Vielleicht in der Innenstadt von Berlin mit 45 WLANs in der Umgebung, die permanent die Luft verschmutzen, am besten noch mit ständigen Broadcasts. Ich lebe aber in einer Gegend, wo um mich rum höchstens 4-5 WLANs gleichzeitg aktiv sind und darüber hinaus sitze ich mit meinem ESP direkt vor meinem Access Point, die Verbindung zum Host-Rechner ist natürlich kabelgebunden.
:
Bearbeitet durch User
Hallo, falls Deine ESP-Gegenstelle unter Windows läuft: MS setzt üblicherweise "verzögertes ACK". Es wird erst nach dem 2. Paket oder einem Timeout, wenn keins mehr kommt, quittiert. Ich habe hier mal den erstbesten Link kopiert, die Antwort und die Reg-Keys sind das interessante. https://social.technet.microsoft.com/Forums/windows/en-US/9f476410-a7a6-4f5d-b9a9-0a63a2bab121/tcpackfrequency-and-nagle?forum=w7itpronetworking Der ESP wartet generell auf das ACK für sein gesendetes Paket, er benutzt kein DelayedACK, das würde mehr Buffer für die TCP-Pakete nötig machen. Ich hatte das Problem auch mit eigener Software, die Daten direkt von SPIFFS per HTTP sendete. Wie sich Linux und Android da verhalten weiß ich nicht. Gruß aus Berlin Michael
:
Bearbeitet durch User
Michael U. schrieb: > Der ESP wartet generell auf das ACK für sein gesendetes Paket, er > benutzt kein DelayedACK, das würde mehr Buffer für die TCP-Pakete nötig > machen. Wenn man an die ESP Firmwäre ran kame: Das könnte man trivial abstellen, indem man die fertigen TCP Pakete einfach zweimal sendet. Dann kommt das ACK sofort, auch bei Windows.
Michael U. schrieb: > falls Deine ESP-Gegenstelle unter Windows läuft: MS setzt üblicherweise > "verzögertes ACK". Es wird erst nach dem 2. Paket oder einem Timeout, > wenn keins mehr kommt, quittiert. Meine ESP-Gegenstelle läuft sowohl unter Windows, Linux (Banana Pi mit Raspbian) als auch Android. Mein Aufbau ist grundsätzlich so, dass ich mit cURL eine kleine HTTP-Anfrage an den ESP sende mit einem selbstdefinierten Header ("req: xxx"). Mit diesem kann ich dem ESP einfach mitteilen, wie viele Dummy-Bytes er mir zurücksenden soll. Ich habe in den letzten Tagen die Anfragen vermehrt von Windows aus verschickt und dabei das Timing in Wireshark und meinem Logic-Analyzer beobachtet. Von der Linux-Kiste habe ich in der letzten Zeit immer nur große Datenmengen an den ESP gesendet, aber die kurze Antwort des ESP nicht genauer untersucht, weil ich damit primär den Durchsatz von/zu verschiedenen Clients testen wollte. Habe daher gerade auf deine Anregung hin mal dieselbe Anfrage von Linux aus versendet - 100 Bytes angefragt - und durfte feststellen, dass der ESP tatsächlich nach dem "Recveived 100 Bytes" sofort mit "SEND OK" quittierte. Eine Anfrage für 20 KB von Linux aus wird somit ~2 s schneller beantwortet als von Windows aus. Ich werde das mal weiter unetersuchen. Danke für den Hinweis!
Michael U. schrieb: > falls Deine ESP-Gegenstelle unter Windows läuft: MS setzt üblicherweise > "verzögertes ACK". Es wird erst nach dem 2. Paket oder einem Timeout, > wenn keins mehr kommt, quittiert. Das war's tatsächlich in meinem Fall O.O Wieder was dazugelernt. Michael U. schrieb: > Ich habe hier mal den erstbesten Link kopiert, die Antwort und die > Reg-Keys sind das interessante. > https://social.technet.microsoft.com/Forums/windows/en-US/9f476410-a7a6-4f5d-b9a9-0a63a2bab121/tcpackfrequency-and-nagle?forum=w7itpronetworking Genau das hat geholfen. Registry-Einträge angelegt, neu gestartet und schon liegen zwischen dem Versenden und dem "SEND OK" nur noch ein paar Millisekunden. Vielen Dsank dafür!
Hallo, schön wenn es geholfen hat. Gerade mal nachgekramt, hier bin ich darüber gestolpert: Beitrag ""Mini-Webserver" ESP8266/ArduinoIDE" Post vom 16.05.2016 20:28 Wie die Zeit vergeht... ;) Gruß aus Berlin Michael
A.. P. schrieb: > Genau das hat geholfen. Registry-Einträge angelegt, neu gestartet und > schon liegen zwischen dem Versenden und dem "SEND OK" nur noch ein paar > Millisekunden. Vielen Dsank dafür! Dafür ist jetzt u.U. Dein Internet grottenlahm. Ich wäre da mit dem Dank vorsichtig...
Jim M. schrieb: > Dafür ist jetzt u.U. Dein Internet grottenlahm Und der Grund dafür sollte sein? Ich kann das nicht bestätigen und im Übrigen müsste das ja dann bei anderen Systemen, wie z.B. bei meiner Linux-Kiste - die ja ebenfalls von Hause aus das ACK sofort verschickt - ebenfalls langsam sein. Dem ist aber auch nicht so.
:
Bearbeitet durch User
Linux verschickt das ACK nicht sofort. Aber nach einigen Paketen merkt Linux, dass der µC das offensichtlich so erwartet und reduziert die Verzögerungszeit (nur für diesen). In der Praxis klappt das sehr gut.
Stefan U. schrieb: > Aber nach einigen Paketen merkt Linux, dass der µC das offensichtlich so > erwartet und reduziert die Verzögerungszeit (nur für diesen). Nach welcher Regel erkennt Linux das denn? Das Betriebssystem kann doch nicht wissen, was der Gesprächspartner für ein System ist und ob dieses verzögerte ACKs erwartet bzw. verkraftet. Oder beobachtet es einfach, dass es von einem bestimmten Client immer nur ein TCP-Segment erhält und kein weiteres, bevor das vorherige nicht bestätigt wurde? Merkt Linux sich dieses Verhalten einer bestimmten MAC-Addresse für die gesamte Uptime oder vergisst Linux diese Eigenschaft nach einiger Zeit wieder? Wenn dem so ist, müsste ich ja z.B. nach einem Neustart feststellen, dass zumindest die ersten Segmente noch mit einer starken Verzögerung bestätigt werden, bevor Linux zu schnellerem Ackowledgment umsteigt.
A.. P. schrieb: > Und mit 200 ms Paketumlaufzeit soll ich gut bedient sein? Vielleicht in > der Innenstadt von Berlin mit 45 WLANs in der Umgebung, die permanent > die Luft verschmutzen, am besten noch mit ständigen Broadcasts. Ich lebe > aber in einer Gegend, wo um mich rum höchstens 4-5 WLANs gleichzeitg > aktiv sind und darüber hinaus sitze ich mit meinem ESP direkt vor meinem > Access Point, die Verbindung zum Host-Rechner ist natürlich > kabelgebunden. Von Deiner Umgebung hast Du nichts gesagt. Ebenso wenig, wofür Du das Ganze nun verwenden willst. Und ich bleibe dabei: Wenn die Reaktionszeit kritisch ist, dann ist WLAN der falsche Weg. Speziell beim ESP8266 ist auch zu bedenken, daß dieser den WLAN Verkehr und die FW mit einem Prozessor abwickelt. Wenn er also gerade an einer Task im Anwmenderprogram läuft, hast Du Pech gehabt. Das wird der ESP32 vermutlich besser abschneiden.
> Nach welcher Regel erkennt Linux das denn? Ich schätze, dass Linux merkt, wenn der µC immer nur einzelne Pakete sendet und dann offensichtlich auf etwas wartet. Mit Wireshark kann man das Verhalten beobachten. > Wenn dem so ist, müsste ich ja z.B. nach einem Neustart feststellen, > dass zumindest die ersten Segmente noch mit einer starken Verzögerung > bestätigt werden, bevor Linux zu schnellerem Ackowledgment umsteigt. So ist es.
Andreas B. schrieb: > Von Deiner Umgebung hast Du nichts gesagt. Weil diese hier auch nicht von Belang ist. Andreas B. schrieb: > Ebenso wenig, wofür Du das Ganze nun verwenden willst. Selber Grund. Andreas B. schrieb: > Und ich bleibe dabei: Wenn die Reaktionszeit kritisch ist, dann ist WLAN > der falsche Weg. Von Zeitkritisch hat hier nie jemand gesprochen. Es ging lediglich darum, rauszufinden, woher diese 200 ms kommen und wie man diese reduzieren kann, damit der Durchsatz des ESP erhöht werden kann. Andreas B. schrieb: > Speziell beim ESP8266 ist auch zu bedenken, daß dieser den WLAN Verkehr > und die FW mit einem Prozessor abwickelt. Ist mir bewusst. Andreas B. schrieb: > Das wird der ESP32 vermutlich besser abschneiden. Natürlich. Ein STM32F407 mit einem ATWILC1000 würde auch besser abschneiden, aber auch noch mehr kosten. Ich arbeite aber nunmal gerade mit dem ESP8266 mit der AT-Firmware und versuche da das meiste rauszuholen.
:
Bearbeitet durch User
A.. P. schrieb: >> Von Deiner Umgebung hast Du nichts gesagt. > > Weil diese hier auch nicht von Belang ist. Wenn man den Effekt des Registry-Hacks beobachten will, dann ist die Umgebung sehr relevant. IIRC konnte man Verschlechterungen vor allem bei hohem Bandbreitenprodukt (Latenz mal Geschwindigkeit) messen. Ich wollte damit auch nur andeuten das man den Effekt solcher Hacks als Laie nicht überblickt.
Jim M. schrieb: > Ich wollte damit auch nur andeuten das man den Effekt solcher Hacks als > Laie nicht überblickt. Aber ich bin kein Laie in Netzwerken und weiß sehr wohl, was da passiert. Und außerdem ist es meine Netzwerkverbindung und die kann so langsam oder schnell werden, wie ich sie haben will :D Full-HD-Streaming funktioniert bislang einwandfrei :P
:
Bearbeitet durch User
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.