Allgemeines > Atari - Talk

SD Karten und (evtl) auch CF Karten kleiner Größen (1-2GB)!

<< < (15/15)

ari.tao:
Ist doch abgeschlossen, jedenfalls aus meiner Sicht.
Hätte ich auch nicht gedacht, daß ich das bis zur letzten Schraube ausbuchstabieren müßte.

-----

@1ST1, ist der Doppel-CF-Adapter unter Deiner Slim-Floppy von guter Qualität? Die Konstruktion macht eigtl. nicht den Eindruck, als sei sie zum häufigen Stöpseln gemacht. Ich habe jüngst zweimal schlechte Erfahrungen mit China-Produkten gemacht: Ein Laufhaus in der Bucht hat mir anscheinend B-Ware teuer verhökert (diese schwarzen Doppel-CF-IDE-Adapter, von denen ich einen in bester Qualität seit Jahren in Benutzung habe), und  einer dieser jetzt häufigen roten CF-SD-Adapter ist zwar von guter Produktion, aber von der Konstruktion her so zart beseitet, daß man ihn unmöglich ´robust´ nennen kann.

ari.tao:
Das Clonen einer 4GB-Card dauert an meinem Falcon über IDE eine gute Stunde und an meinem TT über SCSI+Yamaha noch ca. eine viertel Stunde länger; ca. 40% der Zeit wird zum Lesen benötigt und folglich ca. 60% zum Schreiben. Wer will, kann sich ja jetzt die ´TransferRate´ ausrechnen. Sie stimmt cum grano salis mit dem überein, was einschlägige Test-Prge. als Maximum ergeben (oder auch die Literatur - wo hab´ ich denn das mal gelesen? bei MR?).

Wenn nun einer glaubt, 4GB sei eine ganze Menge Stoff - dann hat er Recht! Auch für große BGM-Partitionen gilt:

--- Zitat --- Man kann also immer noch sehr sehr sehr viele Dateien unterbringen. 
--- Ende Zitat ---
Auf meinem 4GB-Plättle sind es inzwischen mehr als 108.000! Und das Plättle ist erst zu ca. 80% voll. Wie viele Cluster belegt dann eine Datei im Durchschnitt? Und wie viel Verschnitt ist dann bei vorgegebener Cluster-Größe zu erwarten? Na, ich will jetzt aber wirklich nicht den Dreisatz abfragen; sondern, wen´s  interessiert, der kann sich meine private Statistik im Anhang ansehen. Ich hatte zT. Verschnitt > 50% und bin darum reumütig von BGM-Partitionen > 255MB wieder abgerückt.

Vielen Dank auch an @SolderGirl für den Link zu PPERA. Ich hatte zwar schon früher mal da ´reingeschaut, aber erst jetzt ist mir aufgefallen, daß PPERA einen Zusammenhang der Clusterung mit der TransferRate sieht. Hat er Recht?

SolderGirl:

--- Zitat von: ari.tao am Mo 11.07.2016, 02:19:30 ---Vielen Dank auch an @SolderGirl für den Link zu PPERA. Ich hatte zwar schon früher mal da ´reingeschaut, aber erst jetzt ist mir aufgefallen, daß PPERA einen Zusammenhang der Clusterung mit der TransferRate sieht. Hat er Recht?

--- Ende Zitat ---

Die Clustergröße, oder allgemeiner gesagt die Blockgröße eines Transfers hat beträchtlichen Einfluss. Das ist mir schon aufgefallen als ich einen kurzen Test geschrieben habe um die Geschwindigkeit meiner RAM-Disk im Pofo zu messen.
Ich denke das hängt vor allem mit den internen Strukturen zusammen wie das Betriebssystem das jeweilige Dateisystem implementiert hat.
Naive, ungeprüfte Erklärung:
1. Jeder Lese-/Schreibzyklus hat etwas "Verschnitt". Daher geht die effektive Datenrate bei sehr kleinen Blockgrößen zurück.
2. Die Implementierung des Dateisystems sieht irgendwelche Puffer für Datenstrukturen vor. Der RAM-Cache des Systems ist in einer bestimmten Art organisiert. Daraus ergibt sich eine maximale Größe. Wird diese überschritten, dann werden die Zugriffe ebenfalls ineffizient und die Datenrate bricht ein.
Ergo: Man muß experimentieren und die ideale Blockgröße selbst herausfinden.

Das gleiche Phänomen habe ich erlebt als ich mal in meinem Rechner ein RAID-1 Array aus Festplatten eingebaut hatte. Je nach Stripe-Size (Blockgröße der Schachtelung) war die Datenrate fast doppelt so hoch wie bei einer einzelnen Platte, oder auch niedriger als bei einer einzelnen. Hat mich eine ganze Weile gekostet das Array jedes mal mit einer anderen Stripe-Size neu zu erstellen, neu zu formatieren, Geschwindigkeit zu testen und wieder neu formatieren (repeat until done...)

Ich denke das es auch beim Atari irgendwo eine optimale Clustergröße gibt. Darunter spart man Speicherplatz wegen "Verschnitt", verliert aber Geschwindigkeit. Darüber wird es einfach nurnoch ineffizient, wenn das OS einen Cluster nichtmehr "am Stück" verarbeiten kann.

Und neben der Datenrate gibt es ja noch die Latenz. Also die Zeit von der Anfrage des Betriebssystems an den Treiber einen Sektor von der Platte zu lesen, bis diese Daten wirklich verfügbar sind. Diese wird natürlich mit zunehmender Blockgröße ebenfalls größer.

Also:
1. Bei einem Laufwerk das viele kleine Dateien enthalten soll und diese schnell angesprochen werden sollen, ist eine kleinere Blockgröße sinnvoll, auch wenn dadurch die Netto-Datenrate zurückgeht. Beispiele dafür wäre ein Laufwerk mit Sourcen auf dem man kompilieren will.
2. Bei einem Laufwerk mit größeren Dateien, die eher einzeln angesprochen werden, kann die Blockgröße deutlich größer sein. Der "Verschnitt" durch die FAT fällt bei großen Dateien (>100kB) nicht mehr so stark ins Gewicht, dafür wird hier beim kopieren die Netto-Datenrate interessant.
Als Beispiel aus der Atari-Welt fallen mir hier Disketten-Images ein, oder auch Spiele die ihre Daten nicht in unzähligen Dateien verteilt haben.

ari.tao:
Vielen Dank, @SolderGirl, für die sehr ausführliche und schnelle Stellungnahme!

--- Zitat --- Die Clustergröße, oder allgemeiner gesagt die Blockgröße eines Transfers hat beträchtlichen Einfluss.   
--- Ende Zitat ---
Die Clustergröße (die die Organisation des Plättles beschreibt) und die Blockgröße (mit der das BIOS auf das Plättle zugreift (und damit letztlich auch jedes Prg., das die TransferRate mißt)) sind ja nicht identisch. Du hast richtig erkannt, daß meine Frage darauf zielt, ob es sich bei PPERAs Beobachtung vielleicht um ein Artefakt infolge einer Art Aliasing handeln könnte, also schlicht der Meßmethode geschuldet ist! (Auf gut deutsch: ein Irrtum?)
...

--- Zitat --- Und neben der Datenrate gibt es ja noch die Latenz. 
--- Ende Zitat ---
Haben CFs, SDs & SSDs noch eine Latenz? (Da dreht sich ja nix).
Deine weiteren Ausführungen sind sehr interessant, darüber muß ich mal meditieren. Hast Du mal ´RAID in Slilizium´ probiert?
Deine beiden Schlußfolgerungen kann man nur unterstreichen.
Sie betreffen aber die Datei-Verarbeitung, Stichwort ´FilesCopy´; mich interessiert hier eher ´SectorCopy´.  (Über das GEMDOS dauert das Clonen von 4GB einen ganzen Tag lang!)
PPERA behauptet iZshg. mit seinem ACSI-IDE-Adapter und ´geeigneter´ CFs eine verblüffend hohe TransferRate via DMA erzielt zu haben. Hat jmd. das Teil mal ausprobiert? Was sagen unsere Elektroniker dazu?

SolderGirl:

--- Zitat von: ari.tao am Mo 11.07.2016, 13:26:23 ---Haben CFs, SDs & SSDs noch eine Latenz? (Da dreht sich ja nix).

--- Ende Zitat ---

Die Latenz entsteht hier nicht durch die Hardware. Viel mehr entsteht eine gewisse Latenz dadurch, das das System immer mindestens einen Sektor lesen muss. In der Praxis wird aber wohl immer ein Cluster auf einmal gelesen. Daher ist die Latenz natürlich abhängig von der Sektor/Clustergröße. Eine eventuelle Latenz der Hardware würde hierzu noch addiert werden.

PS: Der "schnelle" Adapter ist kein vollwertiger IDE-Adapter, sondern funktioniert nur mit CF-Karten im 8bit-Modus. Leider.

Navigation

[0] Themen-Index

[*] Vorherige Sete