Test Kingston Ultimate GT im Test: Der größte USB-Stick der Welt mag keinen Kleinkram
Ich glaube Atto wird hier nicht richtig eingesetzt. "4x Overlapped I/O" ist eher ein Modus für HDDs, weil man da gleichzeitig liest, schreibt, der Virenscanner und Windows-Update rummacht. Bei dem Peak von 128k kann man jetzt herumraten, welche Clustersize beim Formatieren einstellen soll. 64k ist bei NTFS das Maximum, alternativ geht ja auch exFAT. Aber muß man nun die 128k durch 4 teilen und 32k wären das Optimum?
Die Atto-Messung mit "Neither" finde ich für USB-Sticks besser geeignet und vervollständigt die Sicht auf die Arbeitsweise des Controllers.
Ich würde mich über eine Nachmessung sehr freuen, die Chance diesen teuren Brocken zu testen werde ich wohl nie bekommen.
Selbst SSDs sind bei kleinen Blöcken langsam und der Verwaltungsaufwand steigt vom Controller bis zum OS. Beim zippen muß man die Kompression abschalten ("nur speichern"), sonst begrenzt man auf vlt. 10MB/s ohne daß es bei Videos/MP3 was nutzen würde.
Seit Jahrzehnten wird im Unix-Umfeld tar eingesetzt, anfangs nur für Bandoperationen, aber auch weil es solche kleinteiligen transfers erheblich beschleunigt, obwohl dabei keine Kompression erfolgt.
Die Atto-Messung mit "Neither" finde ich für USB-Sticks besser geeignet und vervollständigt die Sicht auf die Arbeitsweise des Controllers.
Ich würde mich über eine Nachmessung sehr freuen, die Chance diesen teuren Brocken zu testen werde ich wohl nie bekommen.
Ergänzung ()
scooter010 schrieb:
Selbst SSDs sind bei kleinen Blöcken langsam und der Verwaltungsaufwand steigt vom Controller bis zum OS. Beim zippen muß man die Kompression abschalten ("nur speichern"), sonst begrenzt man auf vlt. 10MB/s ohne daß es bei Videos/MP3 was nutzen würde.
Seit Jahrzehnten wird im Unix-Umfeld tar eingesetzt, anfangs nur für Bandoperationen, aber auch weil es solche kleinteiligen transfers erheblich beschleunigt, obwohl dabei keine Kompression erfolgt.
Zuletzt bearbeitet:
Gleichzeitig gelesen und geschrieben wird bei ATTO nicht, sondern erst geschrieben und dann gelesen. Und was hat das mit dem Clustersize zu tun? Dateien können auch über die Grenzen von Clustern hinaus mit einem einem Befehl gelesen oder beschrieben werden. Der Default Clustersize von 4k ist daher für NTFS in jedem Fall zu bevorzugen, zumal wenn man Datenträger ab und an defragmentieren lässt um zu verhindern das die Fragmentierung extrem wird, denn nur dann hat der Clustersize wirklich Einfluss auf die Länge der Zugriffe, da diese niemals länger als das jeweilige Fragment sein können und die Fragmente können nicht kleiner als ein Cluster sein.
Tramizu schrieb:
Ich sag mal so: wer es braucht :-)
Ich tippe mal als Zielgruppe Apple- Jünger. Da kann ja nix teuer genug sein und Preis- Leistungs- Verhältnis interessiert nicht.
Was ist bloß aus unserer Welt geworden?
Hat denn wirklich niemand mehr ein klein bißchen mehr Zeit? Was ist mit all den portablen HDD's, sind die auch schon wieder out?
Klassikfan
Banned
- Registriert
- Aug. 2009
- Beiträge
- 5.677
Mal eine grundsätzliche Frage: Wieso ist die Leistung bei kleinen Dateien so krass schlechter? Es hat ja wohl nichts mit dem von Windows bekannten Phänomen zu tun, daß das System immer auf eine Bestätigung des Schreibvorganges wartet, was bei vielen kleinen Dsteien naturgemäß länger dauert als bei einer großen mit insgesamt gleichem Volumen. Also was steckt da technisch dahinter?
Man kann ja bei NANDs die Daten nur pageweise (z.B. 8k oder 16k) Lesen oder schreiben, aber eben nicht überschreiben. Dazu muss man erst einen Block löschen und der umfasst z.B. 256, 512 oder 1024 Pages. Daher SSD Controllern Mappingtabellen (Flash Translation Layer) in denen die LBAs den NAND zugeordnet werden und die sind auf 4k Zugriffe optimiert, nehmen aber 512MB bis 1GB pro Terrabyte NAND ein, also 1:1000 bis 1:2000 und verlangen viel Rechenkapazität (der Controller der Samsung 960er hat 7 ARM Kerne) und für diese Mappintabelle geht auch der Großteil des DRAM Caches drauf. Bei Controllern ohne DRAM Cache passt nur ein kleiner Teil davon in deren internen SRAM und daher sind die zwar in Benchmarks ganz gut die nur über kleine Adressräume benchen wie CrystalDiskMark der AS-SSD, verlieren aber bei Alltagsnutzung gegenüber denen mit DRAM Cache deutlich an Performance, weil dann die Zugriffe über immer wieder andere Adressbereiche erfolgen und so und daher der veränderte Teil der Mappingtabelle ins NAND geschrieben und ein anderer nachgeladen werden muss.
Nur können SSD Controller recht viel Leistung verbrauchen und entsprechend warm werden, was bei SSDs weniger ein Problem ist als bei USB Sticks denen weder so viel Leistung zur Verfügung steht noch die gleiche Möglichkeit die Wärme abzuführen. Daher muss man dort mit weit weniger Rechenleistung auskommen und dürften daher keine so aufwendigen Mappingtabellen verwalten können, sondern vermutlich eher ein Mapping auf Ebene von NAND Blöcken durchführen, was aber auch bedeuten würde das beim Überschreiben kleiner Bereiche dann viele Pages des Blocks in dem die Daten sich ändern erst einmal in eine anderen kopiert werden müssen, da man ja nicht einfach Daten überschreiben kann, sondern die überschriebenen Daten immer woanders speichern muss und wenn das Mapping eben nicht pageweise erfolgt, dann muss man eben viele Daten dabei kopieren.
SSDs schaffen zwar 4k QD1 Schreibend mit 50, 100 oder gar 150MB/s , aber nur weil die Controller die Daten erst im Schreibcache bündeln und dann gemeinsam ins NAND schreiben, wird der Schreibcache deaktiviert fällt die 4k QD1 Schreibrate in den kleinen einstelligen MB/s Bereich, sofern der Controller die Einstellung nicht ignoriert. Müssen noch Hundertes von Pages kopiert werden, so landet man schnell im Bereich einiger Kb/s.
Ob es so ist weiß ich nicht, könnte es mir aber gut vorstellen und geboren wurde das Verfahren aus der Knappheit an Resourcen sein, USB Sticks gibt es ja schon recht lange und damals war es noch viel schwerer genügend Rechenleistung mit wenige Leistungsaufnahme für die Controller zu erzielen. Außerdem waren bei früheren NANDs die Pages und Blöcke viel kleiner als bei den heutigen NANDs üblich ist, selbst das 34nm NAND von IMFT hatte 4k Pages und Böcke von 128 Pages und dies war schon viel im Vergleich zu Vorgängergenerationen bei denen es auch Versionen mit Small und Large und Very Lage Page gab, wobei Small dann 512 Byte, Large 2k und 4k schon Very Large waren. Ein Block umfasste damals dann z.B. 32 oder 64 Pages, also gerade 16k oder 32k was heute teilweise die Größe einer Page ist und damit tut so eine einfachere NAND Verwaltung natürlich weit weniger weh als bei den Größen die NAND Pages und Blöcke heute haben. Obendrein sind USB Sticks mal angetreten die Floppy Disk abzulösen und bei denen waren zufällige Schreibzugriffe ja auch alles andere als schnell.
Heute könnte man die Controller von USB Sticks sicher auch so bauen das sie bei zufälligen Schreibzugriffen schneller sind, nur dann wären es im Grund schon SSD Controller, also auch teurer und würden mehr Leistung aufnehmen, da kann der Hersteller des Stick dann auch gleich wie SanDisk bei den Extreme einen SSD Controller verwenden, was bei diesem Stick sicher auch Sinn gemacht hätte und vom Preis her drin gewesen wäre. Andererseits schaut die Masse gerade bei den Stick nur auf die maximalen seq. Transferraten und die kann man auch mit den einfachen USB Stick Controllern erzielen, da man auch bei einem einfachen Mapping die Daten dann schön hintereinander in die Pages eines Blocks schreiben kann.
Nur können SSD Controller recht viel Leistung verbrauchen und entsprechend warm werden, was bei SSDs weniger ein Problem ist als bei USB Sticks denen weder so viel Leistung zur Verfügung steht noch die gleiche Möglichkeit die Wärme abzuführen. Daher muss man dort mit weit weniger Rechenleistung auskommen und dürften daher keine so aufwendigen Mappingtabellen verwalten können, sondern vermutlich eher ein Mapping auf Ebene von NAND Blöcken durchführen, was aber auch bedeuten würde das beim Überschreiben kleiner Bereiche dann viele Pages des Blocks in dem die Daten sich ändern erst einmal in eine anderen kopiert werden müssen, da man ja nicht einfach Daten überschreiben kann, sondern die überschriebenen Daten immer woanders speichern muss und wenn das Mapping eben nicht pageweise erfolgt, dann muss man eben viele Daten dabei kopieren.
SSDs schaffen zwar 4k QD1 Schreibend mit 50, 100 oder gar 150MB/s , aber nur weil die Controller die Daten erst im Schreibcache bündeln und dann gemeinsam ins NAND schreiben, wird der Schreibcache deaktiviert fällt die 4k QD1 Schreibrate in den kleinen einstelligen MB/s Bereich, sofern der Controller die Einstellung nicht ignoriert. Müssen noch Hundertes von Pages kopiert werden, so landet man schnell im Bereich einiger Kb/s.
Ob es so ist weiß ich nicht, könnte es mir aber gut vorstellen und geboren wurde das Verfahren aus der Knappheit an Resourcen sein, USB Sticks gibt es ja schon recht lange und damals war es noch viel schwerer genügend Rechenleistung mit wenige Leistungsaufnahme für die Controller zu erzielen. Außerdem waren bei früheren NANDs die Pages und Blöcke viel kleiner als bei den heutigen NANDs üblich ist, selbst das 34nm NAND von IMFT hatte 4k Pages und Böcke von 128 Pages und dies war schon viel im Vergleich zu Vorgängergenerationen bei denen es auch Versionen mit Small und Large und Very Lage Page gab, wobei Small dann 512 Byte, Large 2k und 4k schon Very Large waren. Ein Block umfasste damals dann z.B. 32 oder 64 Pages, also gerade 16k oder 32k was heute teilweise die Größe einer Page ist und damit tut so eine einfachere NAND Verwaltung natürlich weit weniger weh als bei den Größen die NAND Pages und Blöcke heute haben. Obendrein sind USB Sticks mal angetreten die Floppy Disk abzulösen und bei denen waren zufällige Schreibzugriffe ja auch alles andere als schnell.
Heute könnte man die Controller von USB Sticks sicher auch so bauen das sie bei zufälligen Schreibzugriffen schneller sind, nur dann wären es im Grund schon SSD Controller, also auch teurer und würden mehr Leistung aufnehmen, da kann der Hersteller des Stick dann auch gleich wie SanDisk bei den Extreme einen SSD Controller verwenden, was bei diesem Stick sicher auch Sinn gemacht hätte und vom Preis her drin gewesen wäre. Andererseits schaut die Masse gerade bei den Stick nur auf die maximalen seq. Transferraten und die kann man auch mit den einfachen USB Stick Controllern erzielen, da man auch bei einem einfachen Mapping die Daten dann schön hintereinander in die Pages eines Blocks schreiben kann.
Klassikfan
Banned
- Registriert
- Aug. 2009
- Beiträge
- 5.677
Sehr ausführlich und etwas kompliziert (ist ja wohl auch kein einfaches Thema), aber doch verständlich.
Ist halt schon aufwendig, wenn man, um eine weitere Schaufel in die bereits benutzte Scheune zu legen, erst mal alles raus- und in eine Nachbarscheune umräumen muß. Und je größer die Scheunen, um so komplizierter.
Aber betrifft diese Problematik nicht erst Flash-Speicher, die schon einmal komplett gefüllt waren? Das ist doch dieser Effekt bei SSDs, daß sie am Anfang fixer sind als nach dem ersten kompletten Befüllen, weil erst ab da die Blöcke wieder gelöscht werden, während bis dahin bei jedem Schreiben "leere Scheunen" in Hülle und Fülle verfügbar sind? Müßte da der USB-Stick im neuen Zustand nicht auch erheblich schneller sein?
Ist halt schon aufwendig, wenn man, um eine weitere Schaufel in die bereits benutzte Scheune zu legen, erst mal alles raus- und in eine Nachbarscheune umräumen muß. Und je größer die Scheunen, um so komplizierter.
Aber betrifft diese Problematik nicht erst Flash-Speicher, die schon einmal komplett gefüllt waren? Das ist doch dieser Effekt bei SSDs, daß sie am Anfang fixer sind als nach dem ersten kompletten Befüllen, weil erst ab da die Blöcke wieder gelöscht werden, während bis dahin bei jedem Schreiben "leere Scheunen" in Hülle und Fülle verfügbar sind? Müßte da der USB-Stick im neuen Zustand nicht auch erheblich schneller sein?
Das wäre bei SSDs so, weil dort das Mapping eben sehr fein ist und wenn eine Page eines Block überschreiben wird, kann man einfach die Daten auf eine andere Page schreiben und die LBAs einfach auf die neue Page mappen. Aber wenn das Mapping wie ich vermute bei den Stick Controllern nur pageweise geht, dann kann man dies nicht einfach so machen, sondern muss ja den ganzen Block mit Hunderten Pages auf einen anderen Block mappen und dazu eben die Inhalte der anderen Pages kopieren, zumindest die der belegten Pages sofern dem Controller überhaupt bekannt ist welche belegt sind, denn dies zu wissen bedeute eine Menge Verwaltungsdaten pflegen zu müssen und die müsste er im NAND halten, also auch erst lesen und dann auswerten, braucht also auch eine entsprechende Rechenleistung dann könnte er auch gleich ein Mapping auf Ebene der Pages machen und wäre damit eigentlich schon ein SSD Controller und nicht mehr so billig und sparsam.Klassikfan schrieb:
Nein, den Effekt gab es nur bei den Sandforce Controllern, da diese aus irgendeinem Grund den ich nie nachvollziehen konnte, in der Idle-GC zwar NAND Blöcke freigeschaufelt haben, sie aber erst während des Schreibvorgangs löschen, was andere Controller schon gleich bei der Idle-GC machen. Daher kann man bei den SSD mit Sandforce nur über ein Secure Erase die Schreibrate wie im Neuzustand erzielen und nur bis alle NAND Pages wieder einmal beschrieben sind, bei anderen Controllern reicht es wenn die SSD einmal getrimmt wurde bzw. können sie sowieso so viel schnell schreiben, wie an NAND aus Sicht des Controllers frei ist. weil er ja diesen freien Platz schon in seiner Idle-GC auch gleich gelöscht hat.Klassikfan schrieb:
