Hallo Leute Ich weiss, das Thema kam schon einige male auf bezüglich FatFS-Dateisystem von ChaN (R0.11a). Dennoch habe ich eine Frage, die ich hier noch nicht gefunden habe. Für einen Datenlogger muss ich auf eine 32GB SD-Karte solange Daten abspeichern, bis diese komplett gefüllt ist. Das ganze funktioniert soweit auch einwandfrei, allerdings nur solange, bis eine gewisse Menge an Daten abgespeichert wurde. Danach werden die Schreibvorgänge und das erstellen neuer Ordner immer langsamer und langsamer. Der Datenlogger schreibt dabei auf die SD-Karte Datenblöcke der Grösse 8kB und behält solange ein File offen (f_sync), bis dieses File 32MB gross wird. Anschliessend wird das File geschlossen und ein neues wird als Loggfile eröffnet. Getestet habe ich das so, dass ich mit Hilfe eines Windows-PC's Daten auf die SD-Karte kopiert habe, bis bei dieser nur noch knapp 60MB frei waren. Nun beginnt das Problem - die Schreibzeiten über den Mikrocontroller werden willkürlich länger und wieder kürzer, ich sehe da überhaupt keinen Zusammenhang. Ein weiteres, ähnliches Problem habe ich beim erstellen neuer Ordner. Ist dies SD-Karte wieder fast gefüllt (60MB frei) und erstelle nun einen neuen Ornder mit der FatFs library (f_mkdir), so dauert das teilweise bis zu 26 Sekunden, bis dieser effektiv erstellt wurde. Dabei scheint es einen starken zusammenhang zu geben, wie gross die einzelnen Daten auf der SD-Karte sind. Sind diese klein (30MB), geht das erstellen des Ordners deutlich schneller, als wen die Files gross sind (200MB) - natärlich immer bei fast gefüllter Karte) Verwendete Karte: SDHC Class 10, 32GB Ich hoffe auf einige Hilfreiche Antworten und währe allen Tipps und Feedbacks sehr dankbar. Freundliche Grüsse Peter
Prüfe mal, ob die SD-Karte langsam wird oder FatFS. Ich tippe auf die SD-Karte, die mehr Wear Levelling durchführen muss, wenn der Speicher alle ist. Nachtrag: Wenn der Controller erstmal über 1000+ Dateien/Ordner iterieren muss, dann dauert das schlicht seine Zeit (und braucht viele Lesezyklen). Im Gegensatz zu Windows hält FatFS nicht die gesamte FAT im RAM.
:
Bearbeitet durch User
Peter schrieb: > Für einen Datenlogger muss ich auf eine 32GB SD-Karte solange Daten > abspeichern, bis diese komplett gefüllt ist. Das ganze funktioniert > soweit auch einwandfrei, allerdings nur solange, bis eine gewisse Menge > an Daten abgespeichert wurde. Danach werden die Schreibvorgänge und das > erstellen neuer Ordner immer langsamer und langsamer. Logisch. Die FAT wird voll, das Suchen neuer freier Cluster dauert dann länger. Überlege mal wie groß die FAT ist und wie lange es dann dauert einen freien Cluster zu finden falls die Karte zu 50% (75%) gefüllt ist. Natürlich ist das nur bei Schreibvorgängen auf neuen Clustern relevant. S. R. schrieb: > Ich tippe auf die SD-Karte, die mehr Wear Levelling durchführen muss, > wenn der Speicher alle ist. Dann wären aber alle Schreibvorgänge lahm...
:
Bearbeitet durch User
Peter schrieb: > Für einen Datenlogger muss ich auf eine 32GB SD-Karte solange Daten > abspeichern, bis diese komplett gefüllt ist. Das ganze funktioniert > soweit auch einwandfrei, allerdings nur solange, bis eine gewisse Menge > an Daten abgespeichert wurde. Danach werden die Schreibvorgänge und das > erstellen neuer Ordner immer langsamer und langsamer. Das ist doch vollkommen logisch. Du Suchvorgänge nach freiem Speicher dauern immer länger. Da die FAT als einfache lineare Liste vorliegt und nicht im RAM gecached wird, müssen sie bei jedem Suchvorgang immer wieder von neuem ganz von vorn eingelesen werden, bis ein freier Cluster gefunden wird. Da das mit zunehmende Füllung natürlich erst immer weiter hinten in der Liste der Fall ist, dauert das Einlesen immer länger. Damit ergibt sich auch gleich eine sehr einfache Optimierung für dein Zugriffsmuster: Du merkst dir einfach, in welchem Sektor der FAT du zuletzt freien Speicher gefunden hast und läßt die Suche immer erst ab diesem FAT-Sektor beginnen. Diese Optimierung hilft natürlich nur bei so einem einfachen Zugriffsmuster mit monoton wachsendem Datenbestand. Für dasselbe in clever muss man schon ein wenig mehr Hirnschmalz investieren. Da hilft es, einen dynamischen Index (sprich: binary tree) über die FAT zu generieren und mitzuführen. Der braucht zwar auch RAM, aber wesentlich weniger als ein kompletter FAT-Cache. Und das Beste: man kann den Speicherbedarf des Baums dem verfügbaren RAM anpassen. Je mehr Speicher er benutzen kann, desto wirkungsvoller kann er die Suchvorgänge nach freiem Speicher beschleunigen. Allerdings: die dynamische Aktualisierung des Suchbaums kostet ihrerseit aber natürlich auch wieder Rechenzeit. Trotzdem lohnt das. Deswegen machen es auch alle ernstzunehmenden Datenbanken und Dateisysteme ganz genau so...
Jim M. schrieb: >> Ich tippe auf die SD-Karte, die mehr Wear Levelling durchführen muss, >> wenn der Speicher alle ist. > > Dann wären aber alle Schreibvorgänge lahm... Nö. Gibt genug Threads hier im Forum darüber, dass Zugriffszeiten auf SD-Karten besser als unvorhersehbar betrachtet werden sollten. Ich denke, der Thread ist abgeschlossen. ;-)
Hallo zusammen Vielen Dank schon mal für die vielen guten Antworten. Gut also ich kann nachvollziehen, dass das Finden von freien Sektoren auf der SD-Karte bei zunehmenden Daten länger dauert. Dann müsste sich ja aber die Zugriffszeiten konstant verlangsamen - also je mehr Daten auf der SD-Karte sind, desto länger werden die Schreibzyklen. Dann kann es ja nicht sein, dass kurzzeitig die Schreibvorgänge wieder sehr schnell sind und dann plötzlich wieder extrem langsam. Irre ich mich da? Ich sehe da den zusammenhang nicht, denn es müssen ja immer die gleichen Schritte durchgeführt werden, nähmlich das Suchen von freien Sektoren/ Clustern. Weiter kann ich auch noch nicht nachvollziehen, worin den die Unterschiede bestehen, ob ich jetzt eine neue Datei eröffne oder ob ich in die selbe Datei schreibe. Den es wird ja bei beiden nach freien Sektoren gesucht, um die Daten zu speichern. Wie unterscheidet die SD-Karte diese "Daten"? (Neue Datei dauert in der Regel extrem viel länger, als in bestehende zu schreiben) Ebenfalls nicht fündig wurde ich, wie man am besten die SD-Karte belegt. Ist es besser, sehr grosse Daten am Stück zu belassen oder nur kleine Dateien zu schreiben, dafür sehr viele? Und weshalb macht das einen Unterschied, ob sehr viele Dateien in einzelnen Ordner sind oder auf mehrere verteilt? Wie gross sollte man den die Datensätze wählen und von was hängt das ab? Ihr seht ich blicke da leider - trotz stundenlanger Informationsbeschaffung - irgendwie noch nicht ganz durch. Die Idee con c-hater kling eigentlich sehr gut - gleichzeitig aber auch sehr kompliziert. Ich dachte, die FatFS-Library von ChaN macht sämtliche Optimierungen bezüglich Zugriffen etc. selber, so dass ich micht mit der SD-Karte nicht "beschäftigen" muss. Ich kann mir nähmlich irgendwie auch nicht vorstellen, dass ich der Erste bin, der mit solchen "grossen" SD-Karten arbeitet. Das Problem besteht bei meinem System nähmlich darin, dass ich sehr wenig Rechenleistung bei sehr wenig vorhandener Energie habe. Dauert der Schreibvorgang zu lange, stellt mein System ab, da die Energiereserven nicht ausreichen. Vielen Dank für eure Hilfe. Grüsse Peter
> Ebenfalls nicht fündig wurde ich, wie man am besten die SD-Karte belegt.
Für optimale Performance legst du auf der SD Karte eine einzige Datei
an, die den gesamten Platz belegt. Und diese Datei befüllst du dann nach
und nach mit den tatsächlichen Daten.
Dann musst du deine Daten natürlich irgendwie selbst strukturieren. und
so erhältst du letztendlich eine Datenbank oder ein Dateisystem in einer
Datei.
> Ich dachte, die FatFS-Library von ChaN macht sämtliche > Optimierungen bezüglich Zugriffen etc. selber, so dass > ich micht mit der SD-Karte nicht "beschäftigen" muss. Die Library wurde wohl eher so geschrieben, dass sie möglichst wenig RAM belegt. Linux und Windows wären diesbezüglich das andere Extrem.
Peter schrieb: > Gut also ich kann nachvollziehen, dass das Finden von freien Sektoren > auf der SD-Karte bei zunehmenden Daten länger dauert. Dann müsste sich > ja aber die Zugriffszeiten konstant verlangsamen - also je mehr Daten > auf der SD-Karte sind, desto länger werden die Schreibzyklen. Nein, denn die (schreibende) Zugriffszeit auf eine SD-Karte ist eben nicht konstant. Ein beliebiger Schreibzugriff kann zwischen "fast nix" und "100 ms" dauern, je nach Karte. Probiere eine andere Karte, ob es mit der besser ist. > Ist es besser, sehr grosse Daten am Stück zu belassen oder nur kleine > Dateien zu schreiben, dafür sehr viele? Erzeuge mal 5000 Dateien in einem Ordner und öffne dann einen grafischen Dateimanager deiner Wahl auf dem PC. ;-) Du musst balancieren zwischen Performance und Datensicherheit. Wenige, sehr große Dateien (Hinweis: auf FAT maximal 2 GB!) sind schneller, aber wenn die Datei kaputt geht, ist der Datenverlust deutlich schlimmer. > Ich dachte, die FatFS-Library von ChaN macht sämtliche Optimierungen > bezüglich Zugriffen etc. selber, so dass ich micht mit der > SD-Karte nicht "beschäftigen" muss. FatFS ist für die kleinsten Controller bestimmt und benutzt möglichst wenig RAM. Die Magie besteht nämlich nicht darin, Zugriffe zu optimieren, sondern erst gar keine Zugriffe zu brauchen (weil die Daten in einem Cache liegen). Für den Cache kannst du ein paar MB RAM veranschlagen, die hast du auf einem kleinen Controller nicht. Fertig. > Dauert der Schreibvorgang zu lange, stellt mein System ab, > da die Energiereserven nicht ausreichen. Da hilft nur ein hinreichend großer Energiespeicher, eine andere SD-Karte oder ein zusätzliches Sicherungsverfahren. Du kannst z.B. den Datensatz erstmal im EEPROM ablegen und - falls die SD-Karte zu langsam ist - es später noch mal versuchen. Kostet natürlich zusätzlich Energie... Probiere ein paar andere SD-Karten aus, diverse Marken und möglichst keine Fälschungen.
Hallo zusammen Gut also geschrieben wurde, dass ein Schreibzyklus zwischen "fast nichts" und "100ms" dauern kann. Damit hätte ich absolut kein Problem, aber das schein so nicht der Fall zu sein. Mein System hat erst Probleme, wenn der Schreibzyklus 4 Sekunden dauert, und das scheint der Fall zu sein. Nach vier Sekunden ist mein Zwischenspeicher gefüllt und beginnt überzulaufen, wenn die SD-Karte nicht bereit ist. Ok, gemäss euren Antworten ist es also am besten, grosse Datnesätze zu haben. Das dachte ich auch, bis ich das in der Praxis getestet habe. Also sehr viele Daten in einem Ordner macht probleme, dass kontte ich auch nachmessen. Allerdings sehr grosse Daten (200MB), wobei so viel Daten vorhanden waren, dass die Karte fast voll ist, führt dann dazu, dass das erstellen eines neuen Ordner extrem lange dauert (26 Sekunden nachgemessen). Wird die SD-Karte ebenfalls fast gefüllt, allerdings mit 30MB Daten, so dauert das Erstellen eines neuen Ordners deutlich weniger lang (8 Sekunden). Beides ist eigentlich viel zu lange, aber der Unterschied ist drastisch. Auf was sollte man beim Kauf einer SD-Karte achten, damit ich diese Probleme in den Griff bekomme respektive verbessern kann? Vielen Dank. Gruss Peter
S. R. schrieb: > (Hinweis: auf FAT maximal 2 GB!) Falsch, es sind 4 GiB-1B, also 4294967295 Bytes :) Peter schrieb: > Auf was sollte man beim Kauf einer SD-Karte achten, damit ich diese > Probleme in den Griff bekomme respektive verbessern kann? Versuch einfach mal eine bessere SD-Karte. Ich habe sehr gute Erfahrungen mit den Samsung Evo SDHC Karten gemacht. SanDisk und Toshiba hingegen haben sporadisch sehr lange Zugriffszeiten. Selbst der SD-Standard sagt, dass das Schreiben großer Blöcke auf einmal besser ist. Ideal (bei SDHC) sind immer 4 MiB am Stück. Viele kleine Dateien sind immer schlecht...
Peter schrieb: > Gut also geschrieben wurde, dass ein Schreibzyklus zwischen "fast > nichts" und "100ms" dauern kann. Damit hätte ich absolut kein Problem, > aber das schein so nicht der Fall zu sein. Achtung: Das gilt für einen Schreibzyklus (und die Zahl wurde hier im Forum als Hausnummer öfter genannt). Wenn du in eine Datei schreibst, hat das u.U. mehrere Schreibzyklen zur Folge, gemischt mit Lesezugriffen, über mehrere Flashblöcke und ohne jeden Cache! Wenn du die Karte fast voll machst, erhöhst du außerdem die Anzahl der Schreibzugriffe aufs Flash - Stichwort "Write Amplification" - was auch ein Grund sein könnte, dass die Karte lahmt. > Allerdings sehr grosse Daten (200MB), wobei so viel Daten vorhanden > waren, dass die Karte fast voll ist, führt dann dazu, dass das > erstellen eines neuen Ordner extrem lange dauert (26 Sekunden > nachgemessen). Kannst du die Ordner nicht im Voraus (beim Einschalten) erstellen, bevor das System anfängt zu loggen? > Auf was sollte man beim Kauf einer SD-Karte achten, damit ich diese > Probleme in den Griff bekomme respektive verbessern kann? Du kannst auf einen vertrauenswürdigen Hersteller, einen vertrauenswürdigen Händler und dein Glück hoffen. Und natürlich mehrere Karten testen. Was du außerdem versuchen kannst, ist folgendes: - sicherstellen, dass die Partition korrekt ausgerichtet ist (die Werksformatierung sollte das sein, deine eigene nicht unbedingt) und eventuell neu formatieren; - die Partition verkleinern, so dass 10% des Flashes unpartitioniert sind (damit gibst du dem Kartencontroller mehr Platz zum Atmen); - verschiedene Karten verschiedener Hersteller testen, und dir die IDs für den "known good"-Fall notieren Dr. Sommer schrieb: > S. R. schrieb: >> (Hinweis: auf FAT maximal 2 GB!) > Falsch, es sind 4 GiB-1B, also 4294967295 Bytes :) Das hängt davon ab, ob dein Treiber intern uint32_t oder int32_t nutzt, beide Varianten wurden verwendet. In diesem Projekt ist der Unterschied aber egal.
S. R. schrieb: > Das hängt davon ab, ob dein Treiber intern uint32_t oder int32_t nutzt, > beide Varianten wurden verwendet. Und ich dachte schon das hängt von der FAT32-Spezifikation von Microsoft ab... Wäre ja auch zu einfach wenn alle Treiber/Geräte das gleiche FAT32 sprechen! Wer int32_t für etwas verwendet das laut Spezifikation definitiv uint32_t verlangt, macht was falsch. Ein solcher Treiber ist nutzlos... S. R. schrieb: > - sicherstellen, dass die Partition korrekt ausgerichtet ist > (die Werksformatierung sollte das sein, deine eigene nicht > unbedingt) und eventuell neu formatieren Richtig, und zwar mit dem Tool von https://www.sdcard.org/downloads/formatter_4/index.html , nicht den Standard-Tools vom OS. S. R. schrieb: > - die Partition verkleinern, so dass 10% des Flashes unpartitioniert > sind (damit gibst du dem Kartencontroller mehr Platz zum Atmen); Der Controller hat typischerweise noch "unsichtbare" Blöcke zum ausweichen. Die SD-Spezifikation verlangt dass die Partition bis zum Ende geht; ist das nicht der Fall ist die Funktionsweise nicht garantiert. Was eher sinnvoll ist, die Karte nicht 100% vollzuschreiben - der Controller weiß ja dank FAT, welche Blöcke noch frei (zum Ausweichen) sind. Bei meinen eigenen Versuchen habe ich keine Verlangsamung bei voller Karte feststellen können. Dramatische Auswirkungen hat aber die Menge der auf einmal geschriebenen Daten sowie der Hersteller...
Dr. Sommer schrieb: > Und ich dachte schon das hängt von der FAT32-Spezifikation von Microsoft > ab... Wäre ja auch zu einfach wenn alle Treiber/Geräte das gleiche FAT32 > sprechen! Wäre ja auch zu einfach, wenn alle Office-Programme das gleiche "Office Open XML" sprechen - die Spezifikation ist auch da von Microsoft, und selbst deren eigene Software hält sich nicht dran. > Wer int32_t für etwas verwendet das laut Spezifikation definitiv > uint32_t verlangt, macht was falsch. Ein solcher Treiber ist nutzlos... Wenn ich mich recht entsinne (ohne Gewähr!), hat Linux lange die Dateigröße implizit auf 2 GB begrenzt, weil lseek() ein signed off_t nimmt. Ja, das war ein Bug. Und besonders Embedded-Geräten (MP3-Player, FM-Transmitter, etc) mit FAT-Support traue ich zu, dass die das auch tun. Daher 2 GB.
Hallo zusammen Ich habe jetzt mal neue SD-Karten bestellt (unter anderem die vorgeschlagene Karte von Samsung) und erwarte morgen/ übermorgen die Lieferung. Bin ja gespannt wie gross der Unterschied zwischen den einzelnen SD-Karten ist. Ich werde diesbezüglich so schnell wie möglich wieder berichten. Aber was ich immer noch nicht verstehe ist, weshalb das so ein enormer Unterschied ist, um ein Ordner zu erstellen bei folgenden Situationen: 32GB fast gefüllt mit jeweils 200MB Daten -> Erstellen eines neuen Ordners ganz am Anfang des Loggens dauert ca. 26 Sekunden 32GB fast gefüllt mit jeweils 32MB Daten -> Erstellen eines neuen Ordners ganz am Anfang des Loggens dauert ca. 8 Sekunden Gemäss erhaltenen Informationen müsste es doch immer besser/ schneller werden, je grösser die Datensätze gewählt sind, den dies bewirkt auch eine einfachere Struktur im Fat-Dateisystem, nicht? Besten Dank für eure Feedbacks. Grüsse Peter
> Wer int32_t für etwas verwendet das laut Spezifikation definitiv > uint32_t verlangt, macht was falsch. Ein solcher Treiber ist nutzlos... Urteile nicht so hart. Es war viele Jahre lang allen Programmierern klar, dass FAT Partitionen und Dateien darauf maximal 2GB groß sein dürfen. Und dass man einen signed Integer verwendet hat, war auch viele Jahre lang üblich. Irgendwann wurde das zugunsten der 4GB Dateien geändert. Wir schleppen noch viele andere Altlasten und Unklarheiten mit uns herum. Damit muss man einfach Leben. Ganz besonders, wenn man im Internet Umfeld programmiert.
Stefan U. schrieb: > Und dass man einen signed Integer verwendet hat, war auch viele > Jahre lang üblich. Das stimmt allerdings. Selbst das (alte) Standard-Java-API verwendet "int" (in Java immer 32bit signed), d.h. max 2 GB Dateigröße. Windows und Linux haben aber keine Probleme mit 4GiB Dateigröße, und da die Karten eines solchen Loggers vermutlich nicht in einem antiken MP3-Player landen, würde ich da dennoch die 4GiB auch nutzen. Bei meinen Experimenten hatte ich da keinerlei Probleme mit. Peter schrieb: > 32GB fast gefüllt mit jeweils 200MB Daten > -> Erstellen eines neuen Ordners ganz am Anfang des Loggens dauert ca. > 26 Sekunden > > 32GB fast gefüllt mit jeweils 32MB Daten > -> Erstellen eines neuen Ordners ganz am Anfang des Loggens dauert ca. 8 > Sekunden Das sind ja katastrophale Werte. Die langsamste Operation die ich je gemessen hab war ca. 2 Sekunden (bei einer SanDisk-Karte). Finde doch mal heraus, welche Operation in der FatFS Library so lange dauert - das Suchen freier Cluster, das Beschreiben des Verzeichniseintrags,...?
Dr. Sommer schrieb: >> 32GB fast gefüllt mit jeweils 32MB Daten >> -> Erstellen eines neuen Ordners ganz am Anfang des Loggens dauert ca. 8 >> Sekunden > Das sind ja katastrophale Werte. Die langsamste Operation die ich je > gemessen hab war ca. 2 Sekunden (bei einer SanDisk-Karte). Finde doch > mal heraus, welche Operation in der FatFS Library so lange dauert - das > Suchen freier Cluster, das Beschreiben des Verzeichniseintrags,...? Bei 32GB ist die FAT Größe ca. 4 MByte. Ein AVR braucht bei 10 MHz SPI schon 3 Sekunden für die nackte Übertragung ohne Overhead. Und da man die Daten auch verarbeiten muss, sind die 8 Sekunden schon recht nahe am Erwartungswert.
Hallo zusammen Habe bereits nachgemessen, welche Funktion so lange dauert. Und zwar bin ich zum Schluss gekommen, dass innerhalb der f_mkdir Funktion die Unterfunktion
1 | dcl = create_chain(dj.fs, 0); /* Allocate a cluster for the new directory table */ |
sehr lange dauert. Es ist allerdings zu unterscheiden, ob die SD-Karte zuvor mit Windows verändert wurde - das heisst irgendein File verändert/ gelöscht/ hinzugefügt wird. Konnte direkt mit der FatFS-Library bereits ein Ordner neu erstellt werden (also nach 26 Sekunden warten) dauert dies beim nächsten Ordner nur noch wenige ms bis eine Sekunde. Also auch nach dem die SD-Karte vollständig entfernt und wieder eingesetzt wurde ist dies so der Fall. Also mir scheint, als ob Windows irgendwas in der "Datenbank" umformatiert, und die FatLibrary das zuerst neu ordnen muss. Ich blicke da aber zu wenig durch um solche Schlüsse zu ziehen. Die SPI-Schnittstelle taktet bei mir mit 8MHz, was gemäss den mir vorliegenden Informationen die maximale zulässige Taktfrequenz sein sollte. Täusche ich mich da? Grüsse Peter
Jim M. schrieb: > Bei 32GB ist die FAT Größe ca. 4 MByte. Ein AVR braucht bei 10 MHz SPI > schon 3 Sekunden für die nackte Übertragung ohne Overhead. > Und da man die Daten auch verarbeiten muss, sind die 8 Sekunden schon > recht nahe am Erwartungswert. Achja, die schwachbrüstigen AVR :) Aber es war gar nie von AVR die Rede, oder hab ich was überlesen? Ein STM32 braucht für 4 MiB lesen bei SDIO und HS 167ms, und wenn man gleichzeitig überträgt und verarbeitet (DMA) braucht das Suchen kaum länger. Hoffentlich merkt sich die FatFS wo sie zum letzten mal einen freien Cluster gesehen hat, um nicht jedes mal von vorne zu suchen...
Peter schrieb: > Und zwar bin > ich zum Schluss gekommen, dass innerhalb der f_mkdir Funktion die > Unterfunktion > dcl = create_chain(dj.fs, 0); /* Allocate a cluster for the new > directory table */ > sehr lange dauert. Ah, das war zu erwarten. Jetzt musst du darin noch herausfinden, ob das Suchen derart lange dauert und ob es da keinen Cache gibt. Hatte das FatFS nicht eine Caching-Option (fastseek oder so)? Hast du die eingeschaltet?
Also die fastseek-Option habe ich gesehen, hab da aber ehrlichgesagt nicht ganz verstanden, für was die gut sein soll. Wenn du mir also sagst, dass das gut sein könnte, dann lese ich mich da noch genau ein. Besten Dank Grüsse Peter
Dr. Sommer schrieb: > Ein STM32 braucht für 4 MiB lesen bei SDIO > und HS 167ms, und wenn man gleichzeitig überträgt und verarbeitet (DMA) > braucht das Suchen kaum länger. Das passt nicht mit FATFS zusammen. Für diese Controller gibt es passendere FAT Implementationnen, denn da muss man nicht mit Bytes geizen. FATFS geht AFAIK auch nicht mit überschneidendem DMA, jedenfalls nicht ohne viel Frickelarbeit. Peter schrieb: > Die SPI-Schnittstelle taktet bei mir mit 8MHz, was gemäss den mir > vorliegenden Informationen die maximale zulässige Taktfrequenz sein > sollte. Täusche ich mich da? Bei welchem Controller denn bitteschön? SD Karten sind bis 25 MHz für SPI spezifiziert - die Details (wie setup & hold) sind aber leider nicht öffentlich. Es kann durchaus sein dass Dein Controller die nur bis 8MHz erfüllen kann.
Also ich benutze ein MSP430FR5969 Mikrocontrollerboard von TI. Der Controller selber taktet mit 16 MHz, die SPI-Schnittstelle mit 8MHz. Bin mir gar nicht mehr sicher, weshalb ich auf 8MHz kam, aber ich dachte dies sei die Grenze von irgendwas. Könnte sein, dass das die Grenze meiner SPI-Schnittstelle des Controllers war =)
Peter schrieb: > Gemäss erhaltenen Informationen müsste es doch immer besser/ schneller > werden, je grösser die Datensätze gewählt sind, den dies bewirkt auch > eine einfachere Struktur im Fat-Dateisystem, nicht? Nein. Auf das offensichtliche Hauptproblem, die Suche nach freien Clustern, hat es wenig bis keinen Einfluss, wie genau die Daten strukturiert sind. Dafür ist eigentlich nur eine Sache entscheidend: die "allocation strategie", die verwendet wurde, während die bisherigen Daten auf das Medium gelangt sind und die allocation strategie, die verwendet wird, um die neuen Daten zu schreiben. Scheinbar ist die ElmChan-Implementierung immerhin so clever, sich den FAT-Sektor zu merken, in dem die Suche zuletzt freie Cluster gefunden hat. Aber diese Optimierung ist nur relativ klein. Sie endet offensichtlich in dem Moment, wenn die freien Cluster dieses Sektors aufgebraucht sind. Dann wird erstmal wieder eine Runde lineare Suche ganz vom Anfang eingeschoben. Diese kleine Optimierung bringt also nicht wirklich viel, sie genügt aber völlig, um absolut nichtssagende Messwerte zu produzieren, nämlich welche mit extremen Sprüngen, abhängig von der aktuellen Belegung und der Zahl der für einen Vorgang benötigten freien Cluster. Wenn man den Kram allerdings häufig genug mißt und die Ergebnisse kompetent mit den Methoden der Statistik auswertet, dann kommt da doch wieder was aussagekräftiges raus: nämlich, dass die Suchzeiten exponentiell mit dem Datenbestand ansteigen (was angesichts der verwendete Strategie auch nicht anders zu erwarten war)... Und nur ein Index oder ein Cache für die FAT kann daran etwas grundlegendes ändern. Ob dir das nun paßt oder nicht...
c-hater schrieb: > Und nur ein Index oder ein Cache für die FAT kann daran etwas > grundlegendes ändern. Ob dir das nun paßt oder nicht... Ergänzend: Schon eine Index, der nur aus einem einzigen Byte besteht, kann die mittlere Suchzeit theoretisch um ca. den Faktor 8 reduzieren. Ein Index aus drei Byte ca. um den Faktor 16 usw. Natürlich steigt der Gewinn in der Realität nicht ganz so stark an, was sich umso stärker zeigt, je tiefer der Baum ist. Aber 15, 31 oder 63 Bytes Index wären, bezogen auf dein Problem, ganz sicher sehr gut angelegte Bytes. Mehr Performancegewinn pro eingesetztem Byte RAM bekommst du ganz sicher mit keiner anderen denkbaren Methode (jedenfalls nicht bezogen auf universelle Nutzung, für den Fall monoton wachsenden Datenbestands habe ich die optimale Lösung ja bereits gepostet)... Allerdings: wie auch die kleine Optimierung von ElmChan sorgt so ein Index u.U. auch für heftige Sprünge in der Performance. Er muss nämlich erst einmal aufgebaut werden. Und das geht bei einem "neuen" (also für das System neuen) Filesystem entweder dadurch, das man einmal die lineare Suche komplett durchläuft, um ihn vollständig aufzubauen (was entsprechend lange dauert, aber dafür in der Folge keine heftigen Sprünge mehr produziert) oder man baut ihn vollkommen dynamisch im laufenden Betrieb auf, was dann eben für Sprünge sorgen kann, weil zwischendurch immer mal wieder eine Runde lineare Suche mit Indexaufbau erfolgen muss. Bei dem Anwendungsfall mit ab "leer" monoton wachsendem Datenbestand sind allerdings auch ohne initialen Indexaufbau keine großen Sprünge zu befürchten. Da wächst der Index wirklich nahezu unmerklich nebenbei und tut einfach seinen Job.
Vielen Dank für die ausführliche und nützliche Antwort, c-hater. So wie ich mich grad eingelesen habe, könnte die Option mit dem fast_seek tatsächlich etwas gutes sein, nur verstehe ich das ganze nicht wirklich. Je genauer ich die FatFS Library studiere, desto mehr bin ich verunsichert, ob ich das überhaupt richtig mache. Deshalb hier kurz mal den Ablauf, welchen ich verwende: Erstellen eines neuen Files:
1 | f_open(&g_sFileObject, g_pcTmpBuf, FA_WRITE | FA_CREATE_ALWAYS);// öffnen File mit Namen in g_pcTmpBuf |
2 | f_lseek(&g_sFileObject,FILESIZE);// Pre-allocate Clusters, so gross wie File effektiv wird |
3 | f_lseek(&g_sFileObject, 0); // Pointer an Anfang des Files |
Schreiben in das File:
1 | f_write(&g_sFileObject, buffer, size, 0); // Schreiben des Buffers in das eröffnete File |
2 | f_sync(&g_sFileObject); // The f_sync function flushes the cached information of a writing file. |
Schliessen des File:
1 | f_truncate(&g_sFileObject); // Truncate unused area |
2 | f_lseek(&g_sFileObject, 0); // Put file header |
3 | return f_close(&g_sFileObject); |
Ist das so korrekt, dass ich zuerst ein Cluster "Pre-allocate", damit das System weiss, wie gross diese Datei wird? Wie müsste man dies jetzt mit der Fast_Seek Methode erweitern? Vielen Dank für eure Hilfe. Grüsse Peter
Peter schrieb: > Ist das so korrekt, dass ich zuerst ein Cluster "Pre-allocate", damit > das System weiss, wie gross diese Datei wird? Ja, das hilft dir aber kein bissel. Das verlagert nur die gesamte Sucharbeit, die normalerweise (quasizufällig) verteilt über die Schreibzeit einer Datei anfällt, auf den Moment, in dem du die Datei öffnest. Das ist alles. Sprich: das Öffen dauert genau so viel länger, wie später das Schreiben insgesamt schneller geht. Das ist, wie viele kleine Scheisseberge auf einer 100m-Stecke einfach so umzustapeln, dass der ganz große Berg schon direkt am Startblock im Weg liegt... Natürlich hat auch dieser Ansatz seinen Sinn, nämlich immer dann, wenn das eigentliche Schreiben möglichst schnell erfolgen können muss, die Zeit, die zum "Öffnen" der Datei benötigt wird aber irrelevant ist. Das ist aber nicht dein Problem. Für dein Problem hat ElmChan keine Lösung mitgeliefert. Du hast zwei Möglichkeiten: 1) Du machst es dir selber oder 2) du bezahlst jemanden dafür, dass er es dir macht. So einfach ist das.
c-hater schrieb: > Du hast zwei Möglichkeiten: > 1) Du machst es dir selber oder > 2) du bezahlst jemanden dafür, dass er es dir macht. Du hast eine Lösung vergessen: 3) Du nimmst eine Plattform, die dieses Problem nicht hat.
Moin. Was spricht dagegen die sd carte mit einem Windows Tool mit Dateien und Verzeichnissen zu versehen. Der Controller arbeitet dann nur noch mit den bereits bestehenden Dateien und überschreibt nur den Inhalt. Dabei nicht die Dateigröße verändern. Oder Dateien umbenennen. Der overhad um freie Cluster zu suchen entfällt damit. Formatierungparameter prüfen. Clusregrösse fals das hier überhaupt relevant ist. Die Position des ersten Datensektors prüfen, die sollte 2^n sein. Neuere Windows Systeme formatieren bereits entsprechend. Unter Linux kann man das angeben. Hat was mit dem in der sd carte verbauten flash zu tun. Sektoren eines Clusters sind dann nicht über 2flash Kacheln verteilt. Der sd Card mitteilen welche Sektoren gelöscht sind. Gibt glaube ich ein sd Card Commander dafür. Nicht nur auf der fat Ebene. Damit kann die sd Card die ggf vorher schon mal löschen und das Schreiben geht dadurch etwas schneller. Bzw kopiert die nicht benötigten Daten im Hintergrund dumm mit. Gruss.
123 schrieb: > Die Position des ersten Datensektors prüfen, die sollte > 2^n sein. Nein, die ist fix (iirc 4096 Sektoren). 123 schrieb: > Neuere Windows Systeme formatieren bereits entsprechend. Unter > Linux kann man das angeben. Hat was mit dem in der sd carte verbauten > flash zu tun. Besser so: Dr. Sommer schrieb: > Richtig, und zwar mit dem Tool von > https://www.sdcard.org/downloads/formatter_4/index.html , nicht den > Standard-Tools vom OS. 123 schrieb: > Gibt glaube ich ein > sd Card Commander dafür. Nein. Man kann höchstens explizit löschen. Das Mitteilen von nicht benötigten Sektoren geht über die FAT (die dazu natürlich an der richtigen Stelle stehen muss - daher mit dem Spezial Tool formatieren).
S. R. schrieb: > Du hast eine Lösung vergessen: > 3) Du nimmst eine Plattform, die dieses Problem nicht hat. Das ist immer die Lösung aller Idioten: wenn wir keine Ahnung vom Programmieren haben und auch nix dazu lernen wollen oder können, nehmen wir einfach eine Hardware mit mehr Resourcen... Und dann fallen diese ganzen Pisser irgendwann reihenweise auf die Schnauze, wenn sie merken, dass Systeme, die reichlich Hardware-Ressourcen haben, vor allem auch noch was anderes haben: einen sehr viel höheren Energiebedarf...
@Dr Sommer. Zum Löschen von sektoren Sd Card specification sagt da was anderes. Cmd32 cmd33 und cmd38. Acmd23 Die Karten können auch anders formatiert sein oder sogar partitioniert. Da darf die Karte nicht von selbst irgend welche Sektoren als leer betrachten und für was anderes verwenden. Hab ich auch noch nicht beobachtet. Und erlichgesagt nem frisierten 8051 trau ich das auch nicht zu nandflasch Verwaltung, Wareleveling und dann noch fat auswerten. Zur Position des ersten Daten Sektors. Kann ich mich täuschen wir hatten da nur deutliche Unterschiede bei USB sticks festgestellt bei XP vs W7 FAT32 Formatierung. Und das gleiche Zeit auch bei einer sd Card auf. Im Hintergrund werkelt immer ein grosser nand flash
123 schrieb: > Die Karten können auch anders formatiert sein oder sogar partitioniert. Das können sie natürlich. > Da darf die Karte nicht von selbst irgend welche Sektoren als leer > betrachten und für was anderes verwenden. Richtig, das dürfen sie nicht. > Hab ich auch noch nicht > beobachtet. Richtig, machen sie auch nicht. Was sie aber machen: sobald die Partitionierung/Formatierung vom Auslieferungsstandard abweicht, schalten sie in den "Sägemodus", d.h.: sie schalten alle Optimierungen ihrer wear-levelling-Strategie ab, denn die passen eben nur genau zu einem: dem Auslieferungszustand. Der Erfolg ist eine sehr schnell auf unglaublich grottige Werte absinkende Schreibrate und auf längere (aber nicht wirklich lange) Sicht ein deutlich vorzeitiges Verenden des Mediums. Mit ein wenig Glück haben wenigstens einigermaßen kompetente Entwickler die Firmware gebaut, die die Sache dann so lösen, dass nach Vebrauch des letzten Spare immerhin noch jeder beliebige Lesezugriff auf den quasi eingefrorenen letzten gültigen Zustand möglich ist, jedenfalls solange kein Schreibzugriff erfolgt. D.h.: man kann den Scheiß immerhin noch RO mounten und die Daten abziehen. Die Hardcore-Datenvernichter hingegen unterbinden ab dem Crash jeden Zugriff. Die Daten sind dann also definitiv unerreichbar im Nirvana des Flashcontrollers verschwunden. Und das alles passiert genau so bei praktisch allen Flash-Medien, die man heute kaufen kann. Egal ob USB-Stick, SD-Card oder sonstwas. Der Hintergrund ist natürlich eine reine Kostenfrage. Wenn ich z.B. ein 32GB-Medium verkaufen will, dann ist da immer mehr Flash-Speicher drinne. Wieviel mehr, das ist der Knackpunkt bei den Kosten. Mit nur noch ganz wenigen Ausnahmen haben heute deswegen 32GB-Medien alle gerade mal nur 32GiB Flash. Da bleibt echt nicht viel Platz für Spare und den Index für das wear-levelling. Und genau letzteres ist das Hauptproblem und hier setzen die Optimierungen der Flashcontroller an. Sie versuchen, den benötigten Platz für diesen Index zu verringern, damit wenigstens etwas mehr für den ohnehin sehr knappen Spare bleibt. Und das tun sie, indem sie verschiedene Bereiche des Mediums unterschiedlich behandeln (bezüglich der Granularität der im Index gespeicherten Informationen). Und das funktioniert eben nur so lange, wie die Struktur des Mediums den Erwartungen entspricht. Tut er das nicht mehr, wird einfach alles mit der gröbsten Granularität verwaltet. Sprich: die zuvor differenzierte Tiefe des Indexbaums wird vereinheitlicht auf das geringste Niveau. Das ist dann genau das, was ich oben als "Sägemodus" bezeichnet habe. Das bedeutet nämlich nichts anderes, als das sehr viele, eigentlich unnötige Lösch- und Schreibvorgänge auf dem Level der Flashpages passieren müssen. Einfach nur deshalb, weil es der Controller mangels eines hinreichend detaillierten Index nicht mehr besser wissen kann. Und das sorgt dann kurzfristig für drastisch absinkende Schreibraten und längerfristig halt zum vorzeitigen Ausfall des Mediums. Wie auch immer: Flash war und ist von vornherein Beschiss. Kein zuverlässiges Medium, sondern eher Verbrauchsmaterial wie etwa Klopapier. Eigentlich noch schlimmer als Klopapier, da kann man nämlich das Ende der zumutbaren Nutzung immerhin recht zuverlässig abschätzen... Nunja, bei SSDs gibt's ja immerhin S.M.A.R.T. Aber selbst da lügen viele Anbieter wie die Politiker. Wenn sie hier die Wahrheit melden würden, wäre das Modell ja auch noch nichtmal annähernd abverkauft, wenn die ersten Warnungen im Netz erscheinen und potentiellen Kunden für den Rest des Schrotts unter die Augen kommen könnten...
123 schrieb: > Und erlichgesagt nem frisierten 8051 trau ich das auch nicht zu > nandflasch Verwaltung, Wareleveling und dann noch fat auswerten. Der Controller dadrin wertet die FAT nicht aus (die Daten aus dem Flash werden der Performance wegen intern am Controller vorbeigeleitet). Aber der Controller darf durchaus wissen, wo die FAT liegt und Schreibzugriffe auf die entsprechenden Sektoren anders behandeln. c-hater schrieb: > Was sie aber machen: sobald die Partitionierung/Formatierung vom > Auslieferungsstandard abweicht, schalten sie in den "Sägemodus", d.h.: > sie schalten alle Optimierungen ihrer wear-levelling-Strategie ab, denn > die passen eben nur genau zu einem: dem Auslieferungszustand. Was du beschreibst, ist zwar möglich, halte ich aber für unwahrscheinlich (oder zumindest extrem selten). Ich halte es für wesentlich wahrscheinlicher, dass sie sämtliche Optimierungen beibehalten, obwohl das Dateisystem ein anderes ist. Das erklärt die Ergebnisse bei Fremdformatierung genauso gut, erfordert aber deutlich weniger Annahmen. Ich traue den Chips zu, dass sie unglaublich dumm programmiert sind. Ich traue den Chips nicht zu, dass sie intelligent programmiert sind oder sich das Dateisystem anschauen. Quelle sind die Blockschaltbilder, die ich bisher gesehen habe, wo der Datenpfad vom NAND am eigentlichen Controller vorbeilief. > Wenn ich z.B. ein 32GB-Medium verkaufen will, dann ist da immer mehr > Flash-Speicher drinne. Wieviel mehr, das ist der Knackpunkt bei den > Kosten. Mit nur noch ganz wenigen Ausnahmen haben heute deswegen > 32GB-Medien alle gerade mal nur 32GiB Flash. Wenn man bunnie trauen darf, dann ist die Marge bei Flash so gering, dass jeder produzierte Flash-Baustein verkauft wird. Er erwähnte in einem Vortrag mal, dass er mal einen 16 GB-Flash in einer 256 MB SD-Karte gesehen hat. > Wie auch immer: Flash war und ist von vornherein Beschiss. Kein > zuverlässiges Medium, sondern eher Verbrauchsmaterial wie etwa > Klopapier. "Flash does not store your data. Flash stores a stastistical approximation of your data." Ist nicht von mir, aber ich weiß nicht mehr, von wem.
S. R. schrieb: > Was du beschreibst, ist zwar möglich, halte ich aber für > unwahrscheinlich (oder zumindest extrem selten). Ich halte es für > wesentlich wahrscheinlicher, dass sie sämtliche Optimierungen > beibehalten, obwohl das Dateisystem ein anderes ist. OK, diese Interpretation ist tatsächlich (mindestens) genauso denkbar und würde wirklich (fast) zum gleichen Ergebnis führen. Und ich habe auch keine hinreichenden Untersuchungen vorgenommen, um das eine vom anderen unterscheiden zu können. Wäre aber mal spannend, dies zu tun. Schöne Anregung für den anbrechenden Winter... > Ich traue den Chips nicht zu, dass > sie intelligent programmiert sind oder sich das Dateisystem anschauen. Das wäre aber wirklich trivial umzusetzen. Man braucht nur ein bis maximal zwei Sektoren zu überwachen, um das zu tun. Das könnten auch völlig blöde Firmware-Programmierer sicher noch hinbekommen. Aber, wie du völlig korrekt angemerkt hast: warum, zum Teufel, sollten sie eigentlich diesen Aufwand treiben? Das ergibt aus ihrer Sicht tatsächlich keinerlei Sinn. Und wie sollten sie auch überhaupt nur auf die Idee dazu kommen? Dementsprechend neige ich jetzt doch sehr stark dazu, deine Interpretation der Sache als die sehr viel Wahrscheinlichere anzusehen. Vielen Dank für diesen neuen Blickwinkel, den du mir da gegeben hast. Wenn nämlich deine Interpretation zutrifft, könnte man mit (entsprechend angepassten) alternativen Dateisystemen ja sogar durchaus einen nicht unerheblichen Nutzen aus diesem Verhalten ziehen...
c-hater schrieb: > Vielen Dank für diesen neuen Blickwinkel, den du mir da gegeben hast. Gern geschehen. ;-) > Wenn nämlich deine Interpretation zutrifft, könnte man mit (entsprechend > angepassten) alternativen Dateisystemen ja sogar durchaus einen nicht > unerheblichen Nutzen aus diesem Verhalten ziehen... Siehe Samsungs F2FS. Das verhält sich aus Flash-Sicht "ungefähr" wie FAT, ist aber ein sonst modernes Dateisystem (Journal, uid/gid, etc.). Den Aufwand treiben die für ihre Telefone sicherlich nicht umsonst.
Hallo zusammen Besten Dank für die interessanten Kommentare die ihr zum Thema geschrieben habt. Sehr interessant zu lesen. In der Zwischenzeit habe ich noch einige weitere SD-Karten getestet und es sind tatsächlich gewaltige Unterschiede feststellbar. Die Vorgeschlagene SD-Karte von Samsung (Samsung EVO) schlägt sich wirklich recht gut. Allerdings dauert es auch mit dieser SD-Karte teilweise zu lange, so dass mein System nach wie vor abschaltet. Dennoch ist eine deutliche Besserung sichtbar. Was mich auch noch wunder nimmt ist, weshalb die einzelnen Speicherkarten so drastisch in deren Grösse unterscheiden, obwohl beide Karten exakte genau gleich formatiert wurden (SD-Tool, 32KB Cluster). Die Karten unterscheiden dabei direkt nach der Formatierung um knapp 1 GB an verfügbarem Speicher. Woran liegt das? Welcher Platz steht da bei der einen zur Verfügung und bei der andern nicht? Hat das damit zu tun, wie viel Speicherplatz für das FAT benötigt wird? Besten Dank für eure Hilfe. Gruss Peter
Peter schrieb: > Allerdings dauert es auch mit dieser SD-Karte teilweise zu > lange, so dass mein System nach wie vor abschaltet. Deine Software ist prinzipbedingt langsam. Das kann eine schnelle SD-Karte nicht wieder gut machen. > Was mich auch noch wunder nimmt ist, weshalb die einzelnen > Speicherkarten so drastisch in deren Grösse unterscheiden, obwohl beide > Karten exakte genau gleich formatiert wurden (SD-Tool, 32KB Cluster). Vergleiche mal die Größen des Devices (also wieviele Bytes die SD-Karte insgesamt halten kann, ohne Dateisystem). Da wirst du den Unterschied wiederfinden. Die eine Karte ist einfach etwas kleiner als die andere.
Peter schrieb: > Was mich auch noch wunder nimmt ist, weshalb die einzelnen > Speicherkarten so drastisch in deren Grösse unterscheiden, obwohl beide > Karten exakte genau gleich formatiert wurden (SD-Tool, 32KB Cluster). > Die Karten unterscheiden dabei direkt nach der Formatierung um knapp 1 > GB an verfügbarem Speicher. Woran liegt das? Welcher Platz steht da bei > der einen zur Verfügung und bei der andern nicht? Hat das damit zu tun, > wie viel Speicherplatz für das FAT benötigt wird? Hmm, die FAT Größe sollte sich nur ändern, wenn sich die Clustergröße ändert. Da die bei dir fix 32kB ist, sollte das eigentlich keine Auswirkung haben. Haben beide vor der Formatierung wirklich die selbe Größe gehabt? Hast du in beiden Fällen das selbe Formatierungstool mit exakt den selben Einstellungen benutzt? Waren da vielleicht schon Daten drauf?
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.