@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.
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…
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?
