Suche Erklärung für SD-Card Schreib-Delays

Peterchen Gast #1159036
Lesenswert?
• ▲
▼ 
Hallo, mir ist aufgefallen, daß SD-Karten irgendwann mal eine Pause 
einlegen.

Ich schreibe, ohne Unterbrechung, 2048 Bytes durch ein FAT-Dateisystem 
(dieses hier: http://elm-chan.org/fsw/ff/00index_e.html) auf eine 
SD-Karte. Die Karte wird im SPI-Modus betrieben (SPI-Takt = 18 Mhz).

Im Normalfall dauert ein Schreibzugriff für 2048 Bytes 3 bis 4 ms. Hin 
und wieder dauert ein Schreibzugriff aber 150...200 ms. In dieser Zeit 
ist die Karte scheinbar etwas länger beschäftigt.

Ist dieses Verhalten normal (weil die Karte den physikalischen Speicher 
beschreiben muß) oder deutet es auf einen Fehler bei mir hin?

Danke im Voraus,
 Peterchen
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Mike Gast #1159060
Lesenswert?
• ▲
▼ 
Ja, das ist normal, insbesondere bei einer recht neuen Karte. Hin und 
wieder werden beim Schreiben defekte Speicherzellen entdeckt. Dann wird 
ein Reserve-Speicherblock gesucht und der defekte Block umgelagert. Dies 
kann mit einer grösseren Umorganisation des Kartenspeichers verbunden 
sein, die dann eben etwas länger dauert.

Gruss
Mike
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Mike Gast #1159067
Lesenswert?
• ▲
▼ 
Ich habe übersehen, dass Du über ein FAT-System schreibst. Da kann es 
auch vorkommen, dass durch Löschen von Dateien Lücken in der 
kontinuierlichen Speicherbelgung vorhanden sind. Kommt das System beim 
Schreiben ans Ende einer solchen Lücke, muss ein neuer freier 
Speicherbereich in der FAT-Tabelle gesucht werden, was je nach 
Implementierung des Filesystems (freier Pufferspeicher) ebenfalls etwas 
dauern kann. Dieser Effekt kommt zum obengenannten noch hinzu. Hast Du 
mal versucht, eine grosse Datei auf eine vollständig leere (frisch 
formatierte) Karte zu schreiben? Dann sollte die FAT-Speichersuche kein 
Thema sein.

Gruss
Mike
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Peterchen Gast #1159118
Lesenswert?
• ▲
▼ 
Hallo,
Ich habe bei einer frisch formatierten 2GB SD-Card (Agfa-Photo) direkt 
In der Low-Level Schreibfunktion gemessen. So siehts aus:

DiskWrite: (35) 169
DiskWrite: (218) 164
DiskWrite: (4) 159
DiskWrite: (4) 161
DiskWrite: (288) 166
DiskWrite: (10) 160
DiskWrite: (252) 165
DiskWrite: (10) 164
DiskWrite: (252) 165
DiskWrite: (10) 163
DiskWrite: (252) 162
DiskWrite: (10) 162
DiskWrite: (252) 163
DiskWrite: (10) 160
DiskWrite: (252) 165
DiskWrite: (10) 163
DiskWrite: (252) 163
DiskWrite: (10) 165
DiskWrite: (252) 161
DiskWrite: (10) 164
...
...
...

Die Zahl in Klammern ist die Anzahl vorheriger Schreibzugriffe, die 
unter 10ms lagen. Die Zahl danach ist die Zeit für diesen langen 
Schreibzugriff. Auffällig sind die anfänglichen Startschwierigkeiten und 
dann, daß sich dies Delays alle 10 und 252 Zugriffe wiederholen.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Frank G. #1159956
Lesenswert?
• ▲
▼ 
Das liegt an nachfolgenden Punkten:
* NAND ist 8/16bit seriell (kein Addressbus) und wird "quasi" wie eine
  serielle Schnittstelle angesprochen
* es wird immer 1..4 Sektoren (a 512byte) gelesen und ECC-geprüft
* es kann immer nur eine Page (typ 2kB) geschrieben werden (mit ECC)
* es kann immer nur ein Block (typ 128kB) gelöscht werden

Nun multipliziere das mit "wear-leveling" und verwende als Basis mal
typische Zeiten eines Samsung NAND-Flash's.

siehe:
http://de.wikipedia.org/wiki/Flash-Speicher
http://en.wikipedia.org/wiki/Wear_levelling

oder du googlst mal nach diesen KeyWords .

Da nun das Wear-Leveling bemüht ist, die write-Last auf alle Sektoren 
mglst. gleichmäßig zu verteilen, werden bei jedem Schreiben andere phys. 
Sektoren verwendet. Wenn diese bisher andere (ungültige Daten) 
beinhalten, muß erst der Block gelöscht werden. Wenn die frei-Bereiche 
knapp werden oder große "used-cnt" Unterschiede auftreten werden auch 
verwendete Sektoren reorganisiert. Diese müssen aber jederzeit unter der 
entsprechenden logischen Sektoren-Nummer (vom user) ansprechbar sein.

Also, WearLeveling (Mathematik & patentierte Algo's) + phys. 
Eigenschaften + log. Verwaltung ergibt etwa alle "128kB - 2kB" ein 
table-work with erase/update cycle...
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren