So, ne ganze Weile her.
Habe mich bisschen schwer getan mit dem testen, mein Zwischenfazit ist aber wie folgt:
Man bekommt es auf viele Arten schlechter, ganz viele verschiedene Umbauten und Ändrungen kommen aber immer wieder zu ziemlich gleichen Geschwindigkeiten :-/ …
Paar Fragen die sich mir im Zuge des Experimentierens gestellt haben:
Wo kann man die Zuordnung des Web-Tasks und die Priorität anpassen?
Gibt es noch andere möglichkeiten performanter auf die SD-Karte zu schreiben?
Woher kommt der Geschwindigkeits-Peak am Anfang?
– Ziemlich unabhängig von der Buffer Größe
– Vielleicht abhängig von der SD-Karte?
Gehe da gerne noch tiefer, bin für Ideen aber dankbar …
Idealerweise bekommen Webserver-Task (zum Annehmen der Daten) und explorerHandleFileStorageTask (Zum Schreiben der Daten auf SD) ausbalancierte Rechenzeit zugewiesen. Ist ein Task langsamer muss er auf den anderen warten und die Upload-Rate sinkt. Du kannst die Priorität und den Core beim Erzeugen des Tasks setzen, z.B. hier.
Gibt es noch andere möglichkeiten performanter auf die SD-Karte zu schreiben?
Ja mit größerem oder besser gefüllten Puffer. Je mehr Chunks geschrieben werden desto langsamer ist das. Oder Du machst das Schreiben auf SD schneller z.B. mit 4-Bit MMC, dafür braucht man aber 3 GPIOs mehr, die haben wir nicht.
Woher kommt der Geschwindigkeits-Peak am Anfang?
– Ziemlich unabhängig von der Buffer Größe
– Vielleicht abhängig von der SD-Karte?
Ich denke das ist auch ein wenig abhängig vom Browser. Mit MS-Edge Chromium habe ich so einen Peak nicht. Natürlich ist die Berechnung der Upload-Rate zu Anfang ungenauer und pendelt sich erst ein wenn genug Daten übertragen wurden. Ich führe daher die Messung immer zum Schluss durch. 300 KB/s für die ganze Datei ist dann aussagekräftig, egal wie der Status vorher „rumeiert“
Die Optimierung die jetzt erstmal rausgeflogen ist (weil sie fehlerhafte Dateien erzeugte) hat den Ringpuffer besser gefüllt um größere Blöcke/Chunks auf einmal zu schreiben.
Wenn Du das optimieren möchtest kannst Du natürlich alle Kombinationen durchprobieren oder die tatsächliche Taskauslastung messen
@Joe91 Teste mal mit verschiedenen Browsern, Firefox, Chrome, Edge, Safari. Schwankt das immer zu Anfang so stark wie beschrieben?
Vielen Dank für diene Antwort. Bin bis jetzt vor allem mit Firefox unterwegs gewesen.
Die gezeigte Stelle mit dem Task habe ich gefunden (und auch experimentiert damit), der Traffic wird aber ja von einem anderen Task eingetaktet, den ich noch nicht entdeckt habe.
Auch der Rückbau / Umbau deiner Änderung hat bei mir keinen messbaren Unterschied in Firefox gebracht, der Hinweis mit den verschiedenen Browsern ist aber hilfreich!
Ja das ist auch wirklich schwer zu finden weil völlig außerhalb dieses Projekts. Wir verwenden als Webserver ESPAsyncWebserver, der basiert auf AsyncTCP und der Task wird gaanz tief unten hier erzeugt.
Wir pinnen derzeit den Task an einen festen Core in der platform.ini mit
Ein weiteres Bugfix-Release Arduino 2.0.8 wurde soeben veröffentlicht:
Werde es die nächsten Tage mal testen. Was super ist: Die optimierte Verzeichnisauflistung mit getNextFileName(&isDir) nun offiziell enthalten!
Damit ist diese Optimierung auch nicht länger ein Hack. Wenn Alles wie gewünscht funktioniert werde ich dann einen PR dafür erstellen…
Konnte 2.0.8 jetzt mal testen aber es gibt neue Probleme. Durch diesen etwas ungeschickten Bugfix gibt es Fehler beim Komplieren. Ich habe das bereits in der PN5180 Bibliothek angepasst aber für RC522 müsste das der Autor übernehmen. Habe dazu auch ein Issue aufgemacht.
Ich sehe sowohl für 2.0.7 als auch 2.0.8 die ESP-IDF Version 4.4.4. Da hat sich also Nichts geändert.
Irgendwas ist immer - Also nur etwas für die frühen Vögel…
// Get human readable code and type
static const __FlashStringHelper *PICC_GetTypeName(PICC_Type type);
static const __FlashStringHelper *GetStatusCodeName(StatusCode code);
(minirant):
So ganz verstehe ich die Idee mit der Rückgabe von einem __FlashStringHelper * nicht, ich würde hier eher ein const String als Rückgabe erwarten (oder wenn es hardcore C sein soll const char* mit Warnung, dass es ein PROGMEM ist).
__FlashStringHelper ist in erster Linie ein Helper von String um zwischen const char * (liegt im RAM → String verwendet memcpy & co) und const PROGMEM char * (liegt in Flash → String verwendet memcpy_P & co). Das sieht man sehr schön in WString.cpp:170.
Die Regression mit diesem __FlashStringHelper hat wohl so genervt das es jjetzt noch ein neues Arduino-Release gibt:
Das wird wohl auch das letzte Arduino 2 Release (IDF 4.4) sein, die nächste Version 3 wird dann auf dem Espressif IDF 5 basieren. Bis dahin wird aber wohl noch einige Zeit vergehen.
Arduino 2 ist ja schon länger im DEV-Branch verfügbar und scheint reibungslos zu laufen, wer möchte kann es ausprobieren. Sobald es auch ein offizielles PlatformIO package gibt können wir dort die festgepinnten Bibliotheken wieder entfernen.
In den letzten Version 2.0.7-2.0.9 konnte ich auch keine schwankenden Web-Uploadraten mehr feststellen, meine Uploadgeschwindigkeit liegt dauerhaft bei ca. 450 KB/s
Oh, das klingt aber gut. D.h. wir haben jetzt einen gefixten Ringbuffer und dazu die schnellen Uploadraten von vorher?
Ich komme leider aktuell selbst nicht zum Testen, daher muss ich dumm fragen .
ich sage dazu erstmal: JA
Die Sache mit dem schwankenden Upload war ja immer etwas strange & schwer zu reprodzieren. Manchmal trat das einfach nach 5 Resets einfach so auf. Das habe ich aber nicht mehr gehabt. Insgesamt läuft Alles wie gewünscht & ich teste ja auch mit verschiedenen Platinen und Konfigurationen.
Hat noch wer Probleme mit Schwankungen/Einbruch der Uploadrate beim Hochladen aus der Web-UI?
Neue & wohl letzte Runde: Arduino 2.0.10 ist veröffentlicht, ein kleines Bugfix Release basierend auf ESP-IDF 4.4.5.
Hab’s vorab getestet & es läuft Alles wie gewünscht. Sporadische Probleme mit WPA3 Verbindungen bestehen aber weiterhin:
Ab & an öffnet sich der ESPuino dann auch im AP-Modus. Evt. müssen wir bei WPA3 Verbindungsherstellung noch länger warten oder aggressiver neu verbinden…
Wenn das dazugehörige Platform-IO Package veröffentlicht ist werde ich das zeitnah im DEV-Baranch verfügbar machen.
Haben wir eigentlich eine Möglichkeit, WPA3 zu blocken? Also im meinem Fall wäre das (vermutlich) eine feine Sache, ich habe jedoch auf die Schnelle nix gefunden.
Soweit ich weiß kann man in Arduino kann nur den minimalen Sicherheitslevel setzen, z.B.
WiFi.setMinSecurity(WIFI_AUTH_WPA2_PSK);
würde das unsichere WPA deaktivieren & erst Verbindungen ab WPA2 zulassen.
Um WPA3 komplett zu deaktivieren müsste man „Arduino als Komponente“ verwenden und z.B. CONFIG_WPA3_SAECONFIG_WPA3_SAE oder ein anderes Flag auskommentieren.
Bin etwas verwirrt: Unsere aktuelle Version des Packages ist größer, das Arduino darin aber kleiner?
Naja, dann warten wir am besten einfach noch auf ein neues Release
2.0.10 wohl das letzte 2er Release, Version 3 ist in Arbeit und basiert dann auf ESP-IDF 5.0, das wird noch dauern & es wird ein „code-breaking“ Release sein.
Unsere aktuelle Version des Packages ist größer, das Arduino darin aber kleiner?
Meinst Du Programmgröße, RAM oder IRAM?
Jedes 2er Release hat etwas mehr IRAM geschluckt & wir sind da hart an der Grenze wenn alle Features einkompiliert werden sollen. Nur mit Mühe kann noch etwas IRAM in der FastLED Bibliothek freigeschaufelt werden. Mittelfristig funktioniert das dann nur noch über ein angepasstess Arduino-Build mt „Arduino als Komponente“.
Mein Vorschlag wäre diese Möglichkeit schon bald im DEV-Branch verfügbar zu machen, standardmäßig zunächst nicht aktiv. Nur wer Alles will kann das dann aktivieren über eine Zeile in der platform.ini…
Das Thema ist zwar schon etwas ausgelutscht aber es gibt noch Neuigkeiten:
PlatformIO hat Package 6.5.0 veröffentlicht, damit sind wir auf Arduino 2.0.14 bzw. ESP-IDF 4.4.6. Die Release Note sind eher mau für uns:
Schlechte Nachrichten für die Weiterentwicklung: PlatformIO / Espressif scheinen sich ums liebe Geld zu streiten und der PIO Support für Arduino 3 scheint zunächst eingestellt. Ob sich das noch ändert kann man noch nicht abschätzen. Den Thread dazu gibt es hier. Also Bemühungen Richtung Arduino 3 würde ich noch zurückstellen.
Wir können auch den Tasmota Core ins Auge fassen, wenn wir Arduino 3 Unterstützung brauchen. Spätestens ab Juli 2024 (bzw wenn IDF 4.x sein EOL erreicht) sollten wir zumindest mit den Tests starten
…
.