Performance SanDisk Extreme 64GB USB 3.0

So, mein SanDisk Cruzer Extreme 32GB ist gekommen, und ich habe ihn gleich auf Herz und Nieren getestet. Erst im Neuzustand AS-SSD, CrystalDiskMark und ATTO laufen lassen, dann mit Standardeinstellungen (FAT32/16k) formatiert, H2testw komplett durchlaufen lassen, nur 2GB der Testdaten wieder gelöscht und sofort danach im derart "genutzten" Zustand nochmal das volle Benchmarkprogramm durchlaufen lassen. Hier nur exemplarisch die AS-SSD-Werte:

as-ssd-bench SanDisk Cruzer Extreme 32GB FAT32 genutzt.pngas-ssd-bench SanDisk Cruzer Extreme 32GB FAT32 neu.png

Es stellt sich Begeisterung ein: Die Unterschiede zwischen "neu" und "genutzt" liegen im Bereich der Messtoleranzen, während selbst mein bisher schnellster Stick, der Sharkoon Flexi Drive Extreme Duo 16GB, im 4k-Bereich schreibend von anfänglich 0,1 bis 0,5MB/s auf unglaubliche 0,02MB/s und sequentiell von 90 auf 15MB/s eingebrochen ist. Maximale Transferraten von 191MB/s lesend und 119MB/s schreibend in CrystalDiskMark erreichen bzw. übertreffen sogar die "bis zu"-Angaben des Herstellers. Bis jetzt also: Rundherum zufrieden.

Auch an USB 2.0 erreicht der Stick bei mir neue Rekordwerte, schreibend wie lesend gut 34MB/s hat bisher noch kein anderes Gerät geschafft, das spricht für den Controller. Die Random-Werte in CDM streuen jedoch extrem, sind also mit Vorsicht zu genießen.

as-ssd-bench SanDisk Cruzer Extreme 32GB NTFS neu USB2.pngas-ssd-bench SanDisk Cruzer Extreme 32GB NTFS neu.pngCDM SanDisk Cruzer Extreme 32GB FAT32 neu.pngCDM SanDisk Cruzer Extreme 32GB NTFS neu USB2.png

Ich habe hier zum Teil Messungen mit FAT32 und mit NTFS dabei, die Unterschiede waren marginal, ich will hier nicht zu viele Bilder einstellen, sonst wird es zu unübersichtlich.

Thema Windows 8: Mit den Standardtreibern erreicht der Stick sequentiell lesend über 250MB/s, schreibend ergibt sich kein Unterschied. Mit den aktuellen Renesas-Treibern 2.1.39 sind die Werte unter Windows 8 wie unter Windows 7.

ATTO SanDisk Cruzer Extreme 32GB FAT32 neu.pngATTO SanDisk Cruzer Extreme 32GB FAT32 Windows 8 neu.pngCDM SanDisk Cruzer Extreme 32GB FAT32 Windows 8.png

Doch bunt ist in diesem Fall alle Theorie, die Praxis sieht etwas grauer aus. Mit kleinen Dateien ist der Stick für USB-Verhältnisse schnell, keine Frage, und das ist mir extrem wichtig, weil ich Programme davon ausführe. Doch bei Kopiervorgängen in Windows (HDD/SSD -> USB) ergibt sich ein deutlich anderes Bild. Selbst mit großen Dateien (Videos zwischen 1 und 3GB) liegen die Schreibraten erheblich niedriger (etwa Faktor 3) als in den Benchmarks, während die Leseraten in etwa den Benchmarkwerten entsprechen. (Es ist sehr schwer, das zu beurteilen, weil der Windows-Explorer zwar schon niedrigere Werte als in den Benchmarks anzeigt, nach angeblichem Abschluss der Kopieroperationen der Stick aber noch lange nicht fertig mit Schreiben ist.)

Weil mir das keine Ruhe ließ und ich außerdem das Problem habe, dass am Laptop mit älterem Intel-Chipsatz die Schreibwerte nochmals massiv einbrechen, habe ich ein umfangreiches Testprozedere mit H2testw durchgeführt, da das noch am ehesten den Umgang mit großen Dateien widerspiegelt. Dabei habe ich auch gleich die verschiedenen Dateisysteme und auch die für mich wichtige TrueCrypt-Verschlüsselung mit eingebaut.

Desktop-Rechner: AMD Phenom II X4 3,5GHz, SB850 mit Microsoft-USB-Treiber, Renesas uPD720200 mit Treiber 2.1.39
Laptop: Intel Core2 Duo 1,8GHz, ICH8M mit Microsoft-USB-Treiber
Windows 7 SP1 Professional x64
H2testw 1.4, Testdaten 2500MB
TrueCrypt 7.1a
CPU-Limit von TrueCrypt am Laptop bei 130MB/s und am Desktop bei 575MB/s

Code:
				Schreiben [MB/s]		Lesen [MB/s]
				ICH8M	SB850	Renesas		ICH8M	SB850	Renesas		
				USB2	USB2	USB3		USB2	USB2	USB3

FAT32 16k (Default)		13,5	29,1	93,4		27,0	28,8	118
NTFS 4k  (Default)		14,4	30,1	97,0		26,9	28,2	124
NTFS 16k			13,7	29,8	98,6		27,3	28,5	121
NTFS 32k			13,7	29,8	91,9		26,9	28,2	125
exFAT 32k (Default)		13,7	29,2	77,2		27,0	28,3	122
TrueCrypt FAT32 8k (Default)	14,5	27,3	96,0		30,9	31,2	179
TrueCrypt FAT32 16k		14,8	28,1	92,8		31,1	31,2	175
TrueCrypt NTFS 4k (Default)	15,0	28,2	99,4		31,3	31,3	180
TrueCrypt NTFS 16k		15,1	28,0	97,3		30,7	31,4	179
Partitions-Startsektor bei 0k, Alignment stimmt also.

An einigen Stellen gibt es Überraschungen. So erreicht der Stick im Testszenario erst verschlüsselt seine maximale Leserate an USB 3, während er unverschlüsselt um ein Drittel darunter bleibt. Auch an USB 2 besteht ein Vorteil durch die Verschlüsselung beim Lesen von immer noch 10%. Der Einbruch bei den Schreibraten an USB 3 mit dem exFAT-Dateisystem ist ebenso deutlich wie reproduzierbar. Ich habe dort, weil die Werte als einzige so aus dem Rahmen fielen, mehrere Messungen durchgeführt, die Werte zwischen 61 und 88MB/s ergaben, was in jedem Fall unter den übrigen liegt.

Deutlich wird auch, was mich so massiv nervt: Am Laptop liegen die Schreibwerte nochmals um den Faktor 2 unter den üblichen USB-2-Werten. Für mich nicht nachvollziehbar, da die Leseraten mit denen des Desktop-Systems vergleichbar sind.

Für mich bleiben also im Wesentlichen zwei wichtige Fragen: Warum schreibt der Stick im Explorer so massiv langsamer als in den Benchmarks, und warum zur Hölle ist der Intel-Chip dermaßen lahm?

(Ich bin in Sachen Datenträgern wirklich anspruchsvoll, ich kopiere ständig immense Datenmengen zwischen verschiedenen Rechnern und Festplatten hin und her, und die ewige Warterei macht mich fertig. Mit der kleinen Laptop-CPU komme ich dagegen blendend aus.)

Grüße,
Thomas
 
ThommyDD schrieb:
Für mich bleiben also im Wesentlichen zwei wichtige Fragen: Warum schreibt der Stick im Explorer so massiv langsamer als in den Benchmarks, und warum zur Hölle ist der Intel-Chip dermaßen lahm?
Zur ersten Frage würde ich vermuten, dass der Explorer nicht allzu genau die Datenrate anzeigen kann und daher nicht als Benchmark-Tool zu gebrauchen ist. Ich habe in meinem Test für diesen Zweck TeraCopy verwendet, das die benötigte Zeit misst und diese zum Schluss des Kopiervorgangs in MB/s umrechnet (beides ist im Protokoll der Aktion ersichtlich).

Zur zweiten Frage würde ich vermuten, weil es ein Notebook-Chipsatz mit allerhand Stromsparmechanismen ist. Einen ähnlichen Effekt hat man ja auch beim Einsatz von SSDs in Notebooks.
 
So, habe mich gerade mit der Stoppuhr hingesetzt, um bei normalen Kopiervorgängen von SSD auf USB 3.0 mit dem Explorer die Zeit zu messen. Erschütternde Ergebnisse, die mich ratlos zurücklassen:

1 Ordner mit 12 Videodateien von 80 bis 387MiB (gesamt 2681MiB): 3:20 min -> 13,4MiB/s
1 Videodatei mit 2857MiB: 3:10 -> 15MiB/s
3 Videodateien von 2360 bis 2857MiB (gesamt 7676MiB): 6:20 min -> 20,2MiB/s
1 ISO-Datei Windows 8 x64 Enterprise RTM Evaluation mit 3311MiB: 56s -> 59,1MiB/s
3 ISO-Dateien (Windows 7 x64, Windows 8 x64 und Windows 8 x86) von 2402 bis 3311MiB (gesamt 8758MiB): 5:48 -> 25,2MiB/s

Erklärungsversuche und Mutmaßungen meinerseits:

1) Unterschied zwischen einer und mehreren Dateien: Der Explorer verwendet beim Kopieren mehrerer Dateien einen sehr ungünstigen Algorithmus, der den USB-Stick auf eine Art belastet, der er nicht gewachsen ist. Bei den Videos waren die drei am Stück aber sogar etwas schneller.

2) Unterschied zwischen Video und ISO: Der Stick komprimiert die Daten, vielleicht ähnlich wie ein SandForce-Controller. Nicht ins Bild passt, dass der Stick für diesen Test mit TrueCrypt verschlüsselt war, was eine Komprimierung durch den Controller fraglich macht.

Im Übrigen war die Größe der Testdaten in dem vorherigen H2testw-Test bewusst ähnlich groß gehalten, die Unterschiede im Ergebnis sprechen für sich. Bei meinem anfänglichen Test über die gesamte Speicherkapazität lieferte H2testw 97MB/s (tatsächlich sind es MiB/s).

Auf dem Laptop habe ich versuchsweise den selektiven USB-Energiesparmodus abgeschaltet und auch das Energieprofil auf Höchstleistung gestellt, ohne anderes Ergebnis. Im ThinkPad-Forum wies mich ein Nutzer darauf hin, ich hätte vielleicht ein Antivirenprogramm aktiv, was tatsächlich der Fall war. :eek: Die Deaktivierung dessen änderte im Wesentlichen allerdings ebenfalls nichts, der Gewinn lag im Bereich 1-2MB/s. Auf dem Desktop-Rechner ist kein Antivirenprogramm installiert.
 
Auf dem Desktop-System, da ich nur dort USB 3 habe.

Ist denn TeraCopy auch als Alltags-Kopierer zu gebrauchen?
 
ThommyDD schrieb:
Doch bei Kopiervorgängen in Windows (HDD/SSD -> USB) ergibt sich ein deutlich anderes Bild. Selbst mit großen Dateien (Videos zwischen 1 und 3GB) liegen die Schreibraten erheblich niedriger (etwa Faktor 3) als in den Benchmarks, während die Leseraten in etwa den Benchmarkwerten entsprechen.
Da ist die Frage, wo kommen die Daten her, wie schnell ist diese Datenquelle und bremst die der Virenscanner ggf. aus?
ThommyDD schrieb:
(Es ist sehr schwer, das zu beurteilen, weil der Windows-Explorer zwar schon niedrigere Werte als in den Benchmarks anzeigt, nach angeblichem Abschluss der Kopieroperationen der Stick aber noch lange nicht fertig mit Schreiben ist.)
Der Windows Explorer puffert die Daten im RAM und zeigt die Transferrate wohl im wesentlichen basierend auf der Leserate der Datenquelle an, weshalb Dur beim Lesen auch die vollen Geschwindigkeit wie im Benchmark angezeigt wurde, zumindest am Anfang. Erst ganz am Ende des Kopiervorgangs aktualisiert er die Anzeige noch einmal auf einen recht gut passenden Wert, der dann aber wohl von der Geschwindigkeit des Laufwerks bestimmt wird, wo die Daten geschrieben wurden. Beim Kopieren auf den Stick hast Du von Anfang an nur 1/3 der Rate angezeigt bekommen, was darauf hindeutet, dass der Stick schneller hätte schreiben können als die Daten angeliefert wurden, denn in dem Fall puffert der Explorer ja nicht viel, die Schreib- und Leseraten sind recht identisch, die Anzeige ist recht genau und änderst sich auch im allerletzten Moment nur wenig. Wenn das der Fall war, dann hast Du beim Deinem Realtest schlicht die Daten nicht schnell genug gelesen bekommen um die Schreibrate des Sticks auszuloten.

Manche loben die Realtests, aber man sieht auch hier wieder, wie viele Stolperfallen es da gibt die bei den synthetischen Benchmarks vermieden werden!
ThommyDD schrieb:
So erreicht der Stick im Testszenario erst verschlüsselt seine maximale Leserate an USB 3, während er unverschlüsselt um ein Drittel darunter bleibt.
Das ist in der Tat überraschend, aber es könnte dafür zwei Gründe geben:
1. Energiesparzuständen, die bei Verwendung von TC wegen der höhren CPU Auslastung nicht so leicht zuschlagen können.
2. Zugrifflängen: Die Sticks haben ja wie, SSDs auch, eine umso bessere Durchsatzraten, je länger die Zugriffe sind und womöglich gibt es mit TC dann längere Zugriffe als ohne.
ThommyDD schrieb:
Warum schreibt der Stick im Explorer so massiv langsamer als in den Benchmarks
Deine Datenquelle dürfte entweder zu lansam gewesen sein oder sie wurde vom Virenscanner ausgebremst.
ThommyDD schrieb:
und warum zur Hölle ist der Intel-Chip dermaßen lahm?
ThommyDD schrieb:
kopiere ständig immense Datenmengen zwischen verschiedenen Rechnern und Festplatten hin und her, und die ewige Warterei macht mich fertig.
Kannst Du das nicht übers Netzwerk machen?
 
Wie gesagt, die USB-3-Tests sind alle auf dem Desktoprechner gelaufen ohne Virenscanner, er hat nicht mal einen installiert. Beim Realtest kamen die Daten von der Crucial M4 64GB an SATA 6.0GBit/s, zwar verschlüsselt, aber die CPU schafft 575MB/s laut TrueCrypt-Benchmark, was sowohl zum Lesen der Daten von der SSD als auch zum Schreiben auf den USB-Stick dicke reichen müsste. Der Lesebenchmark für das verschlüsselte Laufwerk liegt bei über 300MiB/s, ein Realtest ist mir mangels eines geeigneten Schreiblaufwerks leider nicht möglich, ich muss mir wohl mal eine Ramdisk einrichten. :) (Gibt's da eine gute Freeware?) Das Leselaufwerk als Flaschenhals wage ich trotzdem besten Gewissens auszuschließen.

Das Puffern von Windows ist sehr gut zu beobachten, ich habe zu Beginn der Kopiervorgänge zum Teil Transferraten von 300MiB/s bis 1GiB/s angezeigt bekommen. Bis in den Bereich um 2GiB Datenmenge bleibt das durchaus noch auf einem Niveau weit jenseits von 100MiB/s, dann kommt der Verlauf aber abrupt ins Stocken und schleppt sich dahin. Nach Abschluss des Kopiervorgangs in Windows bleibt der Stick noch etwa 20 Sekunden aktiv und schreibt weiter.

Den Verdacht mit den Zugriffslängen durch die Nutzung von TrueCrypt hatte ich auch, deshalb habe ich verschiedene Clustergrößen probiert. Geändert hat sich dadurch praktisch nichts, was aber nicht heißt, dass das trotzdem eine Rolle spielt, ich stecke da zu wenig drin, wie TrueCrypt die Daten im Detail verarbeitet. Trotzdem bleibt der Unterschied zwischen H2testw (welches mit 1GiB-Dateien arbeitet) und dem realen Kopieren.

Netzwerk scheidet im Normalfall aus, da erstens wenn überhaupt meist nur Internet oder WLAN dafür zur Verfügung stünden (die Übertragungsrate liegt noch weit unter der des USB-Sticks ;-) ) und zweitens einige Rechner bewusst Offline-Rechner sind.
 
ThommyDD schrieb:
ich muss mir wohl mal eine Ramdisk einrichten. (Gibt's da eine gute Freeware?)
Mit ImDisk z.B. lässt sich ganz gut zu Testzwecken eine Ramdisk anlegen.
 
Sorry, das hatte ich vorhin übersehen:
ThommyDD schrieb:
Erklärungsversuche und Mutmaßungen meinerseits:

1) Unterschied zwischen einer und mehreren Dateien: Der Explorer verwendet beim Kopieren mehrerer Dateien einen sehr ungünstigen Algorithmus, der den USB-Stick auf eine Art belastet, der er nicht gewachsen ist. Bei den Videos waren die drei am Stück aber sogar etwas schneller.
Vergiss nicht, es müssen einmal auch die Metadaten (also die Einträge im Filesystem und Directory) geschrieben werden, was kurze und damit langsame Schreibzugriffe zur Folge hat und dann dürfte der Explorer wohl auch nur maximal eine Daten am Stück kopieren, erzeugt also bei kleinen Dateien auch nur kurze Zugriffe die langsamer sind. ATTO zeigt das, verfälscht aber wegen der 4 Overlappung I/Os die Werte nach oben, bei einem Zugriff sind die deutlich schlechter, wie Du im Vergleich der Werte bei 4k mit denen von AS-SSD und CDM siehst.

ThommyDD schrieb:
2) Unterschied zwischen Video und ISO: Der Stick komprimiert die Daten, vielleicht ähnlich wie ein SandForce-Controller. Nicht ins Bild passt, dass der Stick für diesen Test mit TrueCrypt verschlüsselt war, was eine Komprimierung durch den Controller fraglich macht.
Der Controller hat keine Datenkompression. Das kannst Du auch im Kompressionstest von AS-SSD sehen.

ThommyDD schrieb:
Auf dem Laptop habe ich versuchsweise den selektiven USB-Energiesparmodus abgeschaltet und auch das Energieprofil auf Höchstleistung gestellt, ohne anderes Ergebnis.
Auch mit den Einstellungen dürfte die Notebook Chipsätze mehr auch Energiesparen achten als die Desktop Versionen, das steckt bei denen so tief drin, das kann man wohl nicht vollständig deaktivieren.

ThommyDD schrieb:
die CPU schafft 575MB/s laut TrueCrypt-Benchmark, was sowohl zum Lesen der Daten von der SSD als auch zum Schreiben
Der Benchmark ist das eine, aber real wirst Du die Werte trotzdem nicht erreichen, da ja die Daten erst gelesen und dann ver- oder entschlüsselt werden. Benche mal Deine m4 mit AS-SSD und Du wirst sehen, dass die seq. Leseraten unter dem Wert liegt die sie unverschlüsselt schafft, obwohl die CPU laut Benchmark mehr entpacken könnte.

Das hast Du ja aber wohl schon gemacht:
ThommyDD schrieb:
Der Lesebenchmark für das verschlüsselte Laufwerk liegt bei über 300MiB/s
,
ThommyDD schrieb:
Das Leselaufwerk als Flaschenhals wage ich trotzdem besten Gewissens auszuschließen.
Da wäre ich mir nicht so sicher, mache wirklich mal den Test mit der RAM Disk, z.B. der kostenlosen von softperfect (habe die aber nicht ausprobiert).

ThommyDD schrieb:
Das Puffern von Windows ist sehr gut zu beobachten, ich habe zu Beginn der Kopiervorgänge zum Teil Transferraten von 300MiB/s bis 1GiB/s angezeigt bekommen.
Wenn die Transferrate sogar über dem Limit des Quelllaufwerks liegt, dann liegt die Datei noch im Lesecache von Windows. Das verfälscht die Werte bei solchen Realtests auch immer wieder gewaltig, weil man dann plötzlich auch mal zu hohe Leseraten von eigentlich langsamen Laufwerken bekommt.

ThommyDD schrieb:
Bis in den Bereich um 2GiB Datenmenge bleibt das durchaus noch auf einem Niveau weit jenseits von 100MiB/s, dann kommt der Verlauf aber abrupt ins Stocken und schleppt sich dahin. Nach Abschluss des Kopiervorgangs in Windows bleibt der Stick noch etwa 20 Sekunden aktiv und schreibt weiter.
Dann weißt Du jetzt ja genau, was da passiert: Diese 2GB dürfte der Puffergroße entsprechen und Windows lädt den voll, dann wird in dem Masse nachgeladen, wie auch geschrieben wird und die letzten 20s wird nur noch geschrieben, aber die Anzeige Geschwindigkeit im Explorer i.d.R. nicht oder nur einmal ganz kurz am Ende aktualisiert.

ThommyDD schrieb:
Den Verdacht mit den Zugriffslängen durch die Nutzung von TrueCrypt hatte ich auch, deshalb habe ich verschiedene Clustergrößen probiert.
Das die Clustergrößen ein Einfluss auf die Zugriffslängen haben, kann ich mir kaum vorstellen. TC dürfte seine interne Puffergröße nicht davon abhängig machen. Da wird wohl immer eine bestimmte Datenmenge gepuffert, verschlüsselt und weggeschrieben werden, aber in den Quellcode geschaut um das zu prüfen, habe ich auch nicht.

ThommyDD schrieb:
Trotzdem bleibt der Unterschied zwischen H2testw (welches mit 1GiB-Dateien arbeitet) und dem realen Kopieren.
Vorsicht! Die Dateigröße sagt nichts über die Länge der tatsächlichen Zugriffe aus, außer dass die Zugriffe halt länger als die Datei sein dürften. Man kann eine 1GB Datei mit den entsprechenden Befehlen so schreiben, dass jeweils 1 Byte geschrieben wird. Dann puffert Windows normalerweise 32k und schreibt die dann weg, aber man kann das Schreiben auch erzwingen und dann wirklich Byte für Byte an die Platte schicken lassen!
 
So Leute, jetzt wollte ich es aber ganz genau wissen, haltet euch fest. :) DataRAM Ramdisk installiert mit knapp 4GiB, was halt mit der kostenlosen Version möglich ist, formatiert mit NTFS 4k, Stick wieder unverschlüsselt formatiert ebenfalls mit NTFS 4k. Also alle möglichen Flaschenhälse raus.

Zuerst mal mit dem Explorer ein bisschen rumgespielt, den Schreibcache für den Stick in den Laufwerksoptionen des Gerätemanagers aktiviert (Tipp aus dem ThinkPad-Forum), aber trotzdem keine wirkliche Veränderung.

Als nächstes TeraCopy drauf und darin die Benutzung des Windows-Schreibcaches aktiviert. Ergebnis: Die Werte noch schlechter als vorher, an USB 3.0 gerade mal um die 13MiB/s, und nachdem TeraCopy angeblich fertig war mit dem Schreiben der gut 3GiB großen Windows-ISO, blinkte die USB-Stick-LED noch ganze zwei Minuten weiter!!! Ich war fassungslos.

Als Drittes die Benutzung des Windows-Schreibcaches in TeraCopy wieder deaktiviert (also auf Default) und folgendes gemessen (RAM-Disk -> USB 3.0):

1 Ordner mit 15 Videodateien 3673MiB: 4:36min -> 13,3MiB/s
1 Videodatei 2857MiB: 1:03min -> 45,3MiB/s
1 ISO Win8 3311MiB: 1:03min -> 52,6MiB/s

Besser, aber immer noch weit von den Möglichkeiten entfernt. Mit dem Moment, als TeraCopy fertig mit Schreiben war, hörte auch die Stick-LED auf zu blinken.

Zu guter Letzt den Stick wieder mit TrueCrypt verschlüsselt, NTFS 4k, und wieder das volle Programm:

1 Ordner mit 15 Videodateien 3673MiB: 0:39min -> 94,2MiB/s
1 Videodatei 2857MiB: 0:28min -> 102,0MiB/s
1 ISO Win8 3311MiB: 0:33min -> 100,3MiB/s

Und weil es so schön ging, gleich noch meinen üblichen USB-Stick-Inhalt drauf kopiert:

Programme und eigene Dateien (1443 Ordner,12852 Dateien, 3642MiB): 2:41min -> 22,6MiB/s

Begeisterung pur!!! TeraCopy und TrueCrypt in Kombination reizen den Stick bis zum Anschlag aus.

Dann voller Euphorie noch TeraCopy auf dem ThinkPad installiert, getestet (ohne RAM-Disk, da nicht genug RAM drin, sondern Daten von verschlüsselter SSD kopiert), und auf 22MiB/s gekommen, egal ob der Stick verschlüsselt war oder nicht, ob mit AntiVir oder ohne, ob mit höchstem CPU-Takt oder ausbalanciert. Ganze 50% mehr als vorher. Ich denke, damit kann ich erstmal leben.

Also viel Aufregung und jede Menge Arbeit, aber für den Tipp mit Teracopy hat sich das alles echt gelohnt! Danke!

Grüße,
Thomas
 
Teracopy kopiert eine Win8 ISO mit 3,23GB von einer Samsung 840 120GB SSD auf meinen SanDisk Extreme 32GB in 24,6 sek. und umgedreht in 25.5 Sekunden. Das deaktivieren der Windows Schreibcache verschlechtert bei mir das Ergebnis.
 
Vorsicht! Wenn du den Cache aktiv hast und der Stick schneller schreibt als liest, dann sitzt du einem Trugschluss auf! Beobachte die Status-LED des Sticks beim Schreiben! Wenn TeraCopy den Vorgang abschließt, ist der Stick noch lange nicht fertig mit Schreiben! Erst wenn die LED erloschen ist, sind die Daten wirklich drauf, und erst dann kannst du den Stick abziehen, ohne Daten zu verlieren. Bei mir dauert der Schreibvorgang mit Cache ganz erheblich länger (wirklich bis zum Ende, bis also die LED aus ist) als ohne, weil Windows den Schreibzugriff offenbar total verhunzt. Ich bekomme mit aktivem Cache an meinem ThinkPad bei einer 500MiB-Datei eine Schreibrate von über 50MiB/s angezeigt, Dauer 10s, über USB 2! Aber der Stick braucht tatsächlich mehr als dreimal so lange zum Schreiben wie TeraCopy anzeigt (35s) und ist damit langsamer als ohne Cache (22MiB/s).
 
Zuletzt bearbeitet:
ThommyDD schrieb:
den Schreibcache für den Stick in den Laufwerksoptionen des Gerätemanagers aktiviert (Tipp aus dem ThinkPad-Forum)
Bei externen Laufwerken wäre ich damit vorsichtig, da es sehr schnell zu Datenverlusten führen kann, wenn man mal an den Stick kommt und der den Kontakt verliert oder man ihn einfach abzieht statt ihn vorher über "Sicher Entfernen" auszuwerfen.
 
Dessen bin ich mir bewusst, und ich habe mir deswegen angewöhnt, immer die Sicher-entfernen-Funktion zu verwenden, in die ich auch TrueCrypt mittels USB Drive Letter Manager (USBDLM) eingebunden habe (das Windows-eigene Sicher-entfernen-Symbol meldet so erst den Stick oder die externe Festplatte aus TrueCrypt ab und gibt den Datenträger erst dann zum Entfernen frei). Durch die Verschlüsselung wird der Stick als Festplatte erkannt, was ohnehin einen Cache zur Folge hat, unabhängig von der Einstellung im Gerätemanager. Dieser wiederum wird nur durch TeraCopy außer Kraft gesetzt.
 
Was Windows da genau macht wenn der Schreibcache aktiv ist oder nicht, kann ich nicht sagen. Es gibt zwei Möglichkeiten, entweder wird dann über das SATA SET FEATURES Kommando die Platte angewiesen ihren Schreibcache zu deaktivieren oder es wird nach jedem Schreibvorgang der FLUSH CACHE Befehl geschickt, der die Laufwerke auffordert die Daten aus dem Schreibcache auf das Medium zu schreiben.

Da hält sich nicht jedes Laufwerk und nicht jeder Controller dran, was als fsync() faking bezeichnet wird und eigentlich nur für Controller erlaubt ist, die über irgendeine eigene Notstromversorgung sicherstellen können, dass die Daten dann auch im Falle eines Stromausfalls nicht verloren gehen. Die Sandforce Controller machen das aber alle, also auch die Consumerversionen die keine Kondensatoren enthalten. So versucht man halt Reviews zu gewinnen, riskiert aber dafür die Daten der User. Keine Ahnung welche Controller sowas noch machen, aber wenn gerade die 4k Schreibwerte mit und ohne den Harken praktisch gleich hoch sind, dann besteht immer der Verdacht, dass fsync() faking betrieben wird, vor allem wenn deutlich über 10MB/s bei 4k Random Writes erreicht werden.
 
Zurück
Oben