Beschleunigung Webtransfer

@tueddy hat mir netterweise kürzlich einen PR bereitgestellt - vielen Dank an dieser Stelle!

Dabei hat er ein Thema adressiert, dem ich mich schon lange mal annehmen wollte. Und zwar landen die Daten beim Upload per Webbrowser in einem Ringpuffer und werden dann geschrieben. Bisher wurden sie geschrieben, sobald Daten drin waren. Das hat jedoch dazu geführt, dass mitunter auch sehr sehr kleine Blöcke (kleiner 10 Bytes) geschrieben wurden. Annahme: Dies ist nicht effizient.

Neu:
Der Ringpuffer ist nun 8k statt 4k groß und es werden immer nur dann Daten geschrieben, wenn mind. 4k im Ringpuffer liegen. Dies ist notwendig, da immer Blöcke geschrieben werden, die 4k groß sind. Weiterhin wurden Delays ausgebaut und der Watchdog „zwangsgefüttert“. Zur Erinnerung: Der Datentransfer lastet den ESP32 ziemlich aus. Gibt es hier keine Delays oder man füttert den Watchdog nicht selbst, dann provoziert man Neustarts, die der „vernachlässigte“ Watchdog auslöst.

Ziele:

  • Beschleunigung des Transfers.
  • Test, ob 4k-Blöcke vielleicht die Transferabbrüche beheben, die dann auftreten können, wenn die SD-Karte per SPI angebunden ist.

Ergebnisse:

  • Für SD_MMC wurde der Transfer deutlich schneller. Zuvor waren es so 300 kiB/s (meine ich in Erinnerung zu haben), jetzt habe ich so 350/360 kiB/s gemessen. Der Durchsatz schwankt beim Transfer jedoch auch sehr deutlich. Diesen Effekt kannte ich schon aus der Zeit, als noch kein delay vorhanden war (auch für SD_MMC hatte ich daher ein kleines Delay eingeführt). Aber unterm Strich ist das Ergebnis erstmal ok. Ich werde nochmal schauen, ob 1-2 ms Delay vielleicht einen Vorteil bringen könnten.
  • Für SD via SPI funktioniert es nicht, kein Delay zu haben. Der Fehler ist der gleiche wie zuvor: Je kürzer das Delay ist, desto schneller ist zwar die Übertragung, aber desto größer ist auch die Gefahr, dass der Schreibvorgang abreißt. Die Write-Methode liefert irgendwann ein false zurück und ab diesem Punkt kriegt man das auch nicht mehr gerettet (ich habe es mit Extra-Delays von 100ms für diesen Fall getestet). Das läuft dann immer wieder in den Fehler. Mit 10 ms Delay wurde der Abbruch recht selten - ich hab’s jetzt mal auf 11 ms gesetzt. Der Durchsatz beim Schreiben liegt dennoch immerhin bei etwa 180 kiB/s, was (meines Wissens) mehr ist als zuvor. Ergo: Der „4k-Weg“ scheint auch hier vorteilhaft zu sein. Das Write-Problem kriegt man jedoch alleine durch die Erzwingung auf 4k nicht in den Griff.

Hinweise:

  • Der Ringpuffer ist nur für Webtransfer implementiert und nicht für FTP.
  • In Sachen Geschwindigkeit ist der Webtransfer der FTP-Variante überlegen.
  • Die Probleme mit SPI treten bei FTP auch auf.
  • Neu ist das Problem mit SPI offenbar nicht: Problem writing to card in SPI mode - ESP32 Forum.
2 „Gefällt mir“

Hat das jetzt eigentlich auch mal jmd. (außer mir und @tueddy) getestet? :slight_smile:

Hey,

ich hab das gestern testen wollen ( da mein erster Umbau gestern in Betrieb ging)

Sobald ich allerdings etwas hochladen will, oder aber einen neuen Ordner erstellen will startet die Box neu… über FTP hat alles geklappt, wenn auch lahm.

Es handelt sich um einen d32. Ich schau Mal, dass ich ihn anschließe und sehe ob es konkret zu einer Logausgabe kommt…

Ist die SD per SDMMC oder SPI angebunden? Das wäre noch wichtig zu wissen.
Aber ja, poste mal den Fehler. Aber du musst den Stacktrace dekodieren.

Sry, hat ein bisschen gedauert.

Ich verwende die d32 Platine von dir also SPI.

Ich wollte es gerade noch einmal testen und loggen. Hat nun ohne Probelme funktioniert.

ws[/ws][1] text-message[24]: ping
ws[/ws][1] text-message[24]: ping
RSSI: -83 dBm
MQTT: Bin noch online.
ws[/ws][1] text-message[24]: ping
ws[/ws][1] text-message[24]: ping
Schreibe Datei: /mp3/test/003_Das Basketballspiel - Track 3.mp3
ws[/ws][1] text-message[24]: ping
ws[/ws][1] text-message[24]: ping
Datei geschrieben: /mp3/test/003_Das Basketballspiel - Track 3.mp3 => 3361121 bytes in 23404 ms (143 kB/s)
Bytes [ok] 3361121 / [not ok] 0, Chunks: 821

RSSI: -83 dBm
MQTT: Bin noch online.
ws[/ws][1] text-message[24]: ping
Schreibe Datei: /mp3/test/029_Die Kältewelle - Track 6.mp3
ws[/ws][1] text-message[24]: ping
ws[/ws][1] text-message[24]: ping
Datei geschrieben: /mp3/test/029_Die K�ltewelle - Track 6.mp3 => 3157988 bytes in 21305 ms (148 kB/s)
Bytes [ok] 1003565 / [not ok] 2154423, Chunks: 771

Schreibe Datei: /mp3/test/030_Die Kältewelle - Track 7.mp3
ws[/ws][1] text-message[24]: ping
Datei geschrieben: /mp3/test/030_Die K�ltewelle - Track 7.mp3 => 3382850 bytes in 19621 ms (172 kB/s)
Bytes [ok] 706457 / [not ok] 2676393, Chunks: 826

Schreibe Datei: /mp3/test/031_Die Kältewelle - Track 8.mp3
RSSI: -83 dBm
MQTT: Bin noch online.
ws[/ws][1] text-message[24]: ping


Was mir aber aufgefallen ist: Bei einer Mehrfachauswahl von Dateien ist nicht ersichtlich (nach dem bestätigen der Dateiauswahl), dass mehrere Dateien ausgewählt sind. und der Ladebalken geht direkt auf 100% in der Konsole ist aber zu sehen, dass er noch am laden ist. Soll ich mal versuchen das in Screenshots darzustellen?

Ja doch, leider ist es auch hier zu Problemen gekommen.

Das ist ok, da die Zahl bei „not ok“ 0 entspricht.

Hier sieht man nun, dass die Zahl hinten != 0 ist. D.h. nach etwa 1 MB kam es zu einem Fehler.

Teste ich nochmal nach, wobei ich zugeben muss, dass sich @Christian damit erheblich besser auskennt.

Thx,

ich muss zugeben, ich hab die Dateien auch nicht angespielt…