[User-Review] PCIe-4x4 ADATA XPG Gammix S70 Blade 1TB: Halb so schnell wie angegeben und trotzdem zügig

2Stoned

Enthusiast
Thread Starter
Mitglied seit
15.12.2006
Beiträge
272
Ort
Erde
Heute berichte ich über die ADATA XPG Gammix S70 Blade in der 1TB Fassung, die ich im Rahmen eines Lesertests begutachten durfte. Eine Schreibrate von bis zu 6800 MB/s sind schon eine Ansage, die ich hier in der Praxis jedoch nicht erreicht habe. 2 GB/s sind realistisch und bereits durchaus als flott zu bezeichnen. Beginnen wir aber mit einer kurzen Vorstellung des Produkts und den Eckdaten:

Die SSD​

SSD_Front.jpg

Die ADATA XPG Gammix S70 Blade ist eine NVMe SSD im 2280 M.2 Formfaktor mit einem PCIe4 x4 Interface, passt also flach unter die Grafikkarte, die Netzwerkkarte oder was man sonst so über seinen M.2-Slots verbaut, aber auch in eine PlayStation. Für die Leistung ist massgeblich der verbaute InnoGrit-Rainer-IG5236-Controller mit acht Kanälen und 3D-NAND-TLC-Speicherchips von Micron verantwortlich. Unterstützt wird dieser von einem SLC Cache.
SSD_Side.jpg

Herstellerangaben​

Kapazität1 TB
FormfaktorM.2 2280
ControllerIG5236
Masse (LxBxH) ohne Kühler80 x 22 x 4.3mm
Masse (LxBxH) mit Kühler80 x 22 x 3.3mm
Gewicht7 g (10 g mit Kühlkörper)
AnschlussPCIe4.0 x4
Maximale sequenzielle Leserate7400 MB/s
Maximale sequenzielle Schreibrate6800 MB/s
max. IOPS lesend750 000
max. IOPS schreibend750 000
TBW2960 TB

Verpackung​

Geliefert wird die SSD in einer soliden, einfach gehaltenen – aber auffällig roten und mit Perlmutt-Effekt versehener – Schachtel:
Packaging_Front.jpg

Packaging_Back.jpg

Als kleines Gimmick ist auch noch ein Spruch auf die innere Klappe gedruckt:
Packaging_Lid.jpg

Ich mag möglichst ressourcenarme Schachteln, die aber optisch dennoch etwas hergeben. ADATA hat hier meiner Meinung nach einen guten Weg gefunden. Allenfalls hätte die Schachtel noch etwas kleiner sein können, um sich der SSD und dem Kühler mehr anzuschmiegen. So hätte man noch Plastik einsparen können. Der rote Glanz ist ein gelungener Effekt und sticht im Ladengeschäft im Regal heraus.

Einbau​

Eingebaut ist die SSD im Handumdrehen. Gehäuse öffnen. Merken, dass man die falsche Seite des Gehäuses geöffnet hat. Gehäuse wieder schliessen. Andere Seite öffnen. Merken, dass man andere Schraubenzieher benötigt. Schraubenzieher holen. Grafikkarte ausbauen. Kühlelement für die M.2 SSDs entfernen. SSD einstecken. Kühlelement aufsetzen und anschrauben. Grafikkarte wieder einbauen. Gehäuse wieder schliessen. Tada: die SSD ist startklar.
Home.jpg

Geschwindigkeitskontrolle​

Direkt nach dem Einbau teste ich die Leserate: 13 576.45 MB/s gecacht und 3930.82 gepuffert verrät mir
Code:
sudo hdparm -Tt /dev/nvme2n1
Um die Schreibraten zu testen, muss ich zunächst ein paar Partitionen anlegen. Um einen Eindruck davon gewinnen zu können, welchen Einfluss das Dateisystem hat, lege ich vier Partitionen an: BTRFS, ext4, NTFS und XFS, die je ein Viertel der SSD erhalten. Anschliessend kopiere ich mein gesamtes Home-Verzeichnis in die neuen Partitionen und schreiben mit
Code:
sudo dd if=/dev/zero of=/mnt/btrfs/tmpfile bs=1M count=1024 conv=fdatasync,notrunc status=progress
zusätzlich noch 1 Gb an Daten darauf. Dies ergibt folgenden ersten Eindruck:
copy.png

Die versprochenen 6800 MB/s werden also bei Weitem verfehlt, wenn man sich das Kopieren des Home-Verzeichnisses anschaut. Hierbei werden Dateien verschiedener Grösse kopiert, von wenigen kb kleinen Textdateien bis hin zu mehreren GB grossen Datensätzen. Der Kopiervorgang mit dd ist schon näher dran, ist aber auch deutlich synthetischer und entspricht eher den Idealbedingungen für die SSD. Auffällig ist, wie stark die Performance-Einbussen sind, die NTFS mit sich bringt. Beim Kopieren des Home-Verzeichnisses werden gerade einmal 202 MB/s erreicht. XFS knallt dieses mit 839 MB/s richtig hin, wobei BTRFS und ext4 mit 750 MB/s nicht weit ab davon sind.

Ein ähnliches Bild ergibt sich auch bei den mit KDiskMark ermittelten Werten für Schreib- und Lesevorgänge. In jeweils neun Durchgängen habe ich ermittelt, wie schnell 16, 1000 und 64 000 Dateien à 1 MB geschrieben und gelesen werden und wie lange es dauert, 4000 zufällige Zugriffe auf den Speicher zu machen. Für den Benchmark habe ich die Real-World NVMe SSD-Voreinstellungen in KDiskMark gewählt.
Write.png

Beim sequenziellen Schreiben werden über 2 GB/s erreicht. Weniger als die erhofften 6.8 GB/s, aber stattlich. NTFS fällt mit unter 1 GB/s ab.

Read.png

Gelesen wird etwas schneller (ausser BTRFS aus mir noch nicht bekannten Gründen), die vom Hersteller angegebene maximale Lesegeschwindigkeit wird aber um über 50 % verfehlt. NTFS bleibt hier im Feld.

mix.png

Schreiben und Lesen wechseln sich im Alltag meist laufend ab. Der Mix aus 70 % Lesen und 30 % Schreiben zeigt Schwächen von BTRFS als Dateisystem auf. Zudem zeigt sich, dass hierbei 1 GB/s von der SSD erwartet werden kann.

rndwrite.png

Zufällige Schreibvorgänge sind anspruchsvoll. Die verschiedenen Partitionen meistern dies ähnlich gut, mit XFS an der Spitze mit rund 270 MB/s.

rndread.png

Beim zufälligem Lesen hilft weder Puffer noch Cache. Hier ist der Controller gefragt. ext4 und XFS setzen sich an die Spitze und ermöglichen rund 80 MB/s zufällig zu lesen.


rndwriteiops.png

Bis zu 750 000 IOPS gibt ADATA an. ext4 und XFS ermöglichen dies auch fast bei zufälligen Schreibvorgängen. Puffer und Cache kommen hier sicherlich gut zum Tragen.

rndreadiops.png

Beim zufälligen Lesen helfen Puffer und Cache aber nicht mehr. Die IOPS fallen auf etwa 200 000 ab, je nach Dateisystem auch darunter.

Fazit​

ADATA liefert mit der XPG Gammix S70 Blade eine hübsche kleine NVMe SSD, bei welcher im Alltag Schreib- und Leseraten von einigen wenigen GB/s erwartet werden können. Die maximalen Herstellerangaben beziehen sich jedoch – wie eigentlich immer – auf synthetische Benchmarks. Ein flottes System hat man hiermit allemal. Je nach Anwendungsfeld lohnt es sich vorab zu prüfen, welches Dateisystem zum Einsatz kommen soll. Hierbei spielen dann aber natürlich nicht nur die rohen Leistungsdaten eine Rolle, sondern auch das benötigte Featureset.

Nachtrag zum Dateisystem​

Auf alle 4 Partitionen wurden die gleichen Daten geschrieben. Die Speicherbelegung sieht jedoch leicht unterschiedlich aus:
Speicherbelegung.png

BTRFS belegt 32 GiB, XFS 29 GiB und ext4 und NTFS jeweils 27 GiB. Unterschiedliche Designphilosophien, Journaling, Redundanz, Prüfsummen zeigen sich bereits im Kleinen.
 

Anhänge

  • rndmix.png
    rndmix.png
    23,5 KB · Aufrufe: 67
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Danke für das Review. Die Herstellerangaben beim sequentiellen Lesen und Schreiben werden nicht erreicht, da nur mit einem Thread zugegriffen wird. Mit 4 und mehr Threads sollte dieses Problem verschwinden.
Wodurch wird die Aussage, dass es sich um NAND von Micron handelt, gestützt? Auf dem Foto kann ich nur mit ADATA gelabeltes Chips sehen.
 
Danke für deinen Kommentar. Mehr threads helfen nur bedingt. Beispielsweise sequentielles Lesen/Schreiben von 1 GiB in 1MB Blöcken à 8 queues mit 4 threads liefern 3214/2677 MB/s. Die IOPS beim Schreiben von zufälligen 4 kb Blöcken gehen aber auf über 600 000 hoch.

Die Aussage das der NAND von Micron stammt habe ich nach nochmaligen nachschlagen tatsächlich nicht auf der Herstellerseite gefunden, nur in online Medien. hwLUXX nennt dies auch. Ich bin da aber etwas skeptischer. Beispielsweise liefert
Code:
sudo nvme micron vs-nand-stats /dev/nvme2n1
Unsupported drive model for vs-nand-stats command
Ich bin da jetzt eher skeptisch bzgl. dem NAND. Danke fürs Nachfragen!
 
Bleibt die Frage, ob die zu geringe gemessene Leistung am Testprogramm oder der SSD liegt. Mit Programmen wie CDM können die beworbenen sequentiellen Werte bei den meisten SSD i.d.R. annähernd nachvollzogen werden. Die in deinem Profil angegebenen 970evo+ kannst du nicht zur Klärung dieser Frage heranziehen?

Dass das NAND von einem Hersteller mit Reputation wäre, wird den kommerziellen Reviewern überlichweise von den SSD-Herstellern im Rahmen der Übergabe der kostenlosen Testsamples gesteckt. Bei 3rd-Party-Herstellern die NAND-Chips mit eigenen Labeln versehen, ist das aber nicht zu verifizieren.
 
Der Vergleich mit der Evo Plus hinkt etwas, da hier auf eine verschlüsselte BTRFS Partition geschrieben wird. Diese wiederum verspricht 3500/330 MB/s beim Lesen/Schreiben. Gemessen habe ich folgende Werte:

ModusLesen [MB/s]Schreiben [MB/s]
SEQ1M (8Q | 1T)25761949
RND4K (32Q | 16T)727162
RND4K (IOPS)181 79340 406
RND4K (μs)7042657

Die Samsung SSD ist bei diesem Testdurchlauf mit KDiskMark näher an den angepriesenen Werten dran als die ADATA. Die ADAT glänzt hingegen bei den zufälligen Zugriffen, wobei hier wohl das Ver- und Entschlüsseln bei der Samsung entsprechend Leistung kostet.
 
Bei 3rd-Party-Herstellern die NAND-Chips mit eigenen Labeln versehen, ist das aber nicht zu verifizieren.
Doch, mit innogrit_nvme_flash_id.exe unter Windows (von VLO) - so weit ich weiß, haben die älteren Gammix S70 (non-Blade) schon Micron B47R 176-Layer NAND-Chips gehabt... Aber, wie DU sagst: von ADATA umgelabelt (macht Kingston auch oft) und ADATA ist ja oft dabei ertappt Überraschung-Eier zu verkaufen mit stets anderem Inhalt (von der 8200er gibt's mittlerweile 7 (Sieben!) verschiedene Versionen). Die Gewissheit hätten wir also nur wenn der Tester die Komponenten mit dem VLO-Tool ausliest.
 
Aber, wie DU sagst: von ADATA umgelabelt
Da wird nichts umgelebelt, sondern da werden ganze Wafer oder Restwefer, also solche wo Micron schon selbst die guten Chip entnommen hat und dann irgendwo gebinnt und gepackaged und dann kommt da eben ein eigenes Label drauf. Keine Hersteller würde sich die Mühe machen ein Micron Label von einem Chip entfernen um da sein eigenes drauf zu machen, das würde man allenfalls machen wenn das ein Spectek Label drauf ist, denn Spectek ist die Restrampe von Micron. Keiner der Ahnug und etwas Ansprüche an die Qualität hat, wird nämlich eine SSD kaufen wo die NANDs mit Eigenlablen statt dem Label von einem NAND Hersteller wie Micron versehen sind. Wobei ich mir so eine SSD nie kaufen würde.
 
innogrit_nvme_flash_id.exe unter Windows (von VLO)
Code:
v0.141a
OS: 10.0 build 19045
Drive   : 1(NVME)
Scsi    : 2
Driver  : W10
Model   : XPG GAMMIX S70 BLADE
Fw      : 3.2.F.66
Size    : 976762 MB [1024.2 GB]
LBA Size: 512
AdminCmd: 0x00 0x01 0x02 0x04 0x05 0x06 0x08 0x09 0x0A 0x0C 0x10 0x11 0x14 0x80 0x81 0x82 0xC2 0xC7 0xC8 0xC9 0xD0 0xD6 0xDA 0xE4 0xE5 0xE6 0xF0 0xF2 0xF7 0xFF
I/O Cmd : 0x00 0x01 0x02 0x09
Ctrl/DID: 5236
F/W     : 3.2.F.66
Bank01: 0x9b,0xc4,0x28,0x49,0x20,0x0 - YMTC 3dv3-128L TLC 16k 512Gb/CE 512Gb/die 4Plane/die
Bank03: 0x9b,0xc4,0x28,0x49,0x20,0x0 - YMTC 3dv3-128L TLC 16k 512Gb/CE 512Gb/die 4Plane/die
Bank09: 0x9b,0xc4,0x28,0x49,0x20,0x0 - YMTC 3dv3-128L TLC 16k 512Gb/CE 512Gb/die 4Plane/die
Bank11: 0x9b,0xc4,0x28,0x49,0x20,0x0 - YMTC 3dv3-128L TLC 16k 512Gb/CE 512Gb/die 4Plane/die
Bank17: 0x9b,0xc4,0x28,0x49,0x20,0x0 - YMTC 3dv3-128L TLC 16k 512Gb/CE 512Gb/die 4Plane/die
Bank19: 0x9b,0xc4,0x28,0x49,0x20,0x0 - YMTC 3dv3-128L TLC 16k 512Gb/CE 512Gb/die 4Plane/die
Bank25: 0x9b,0xc4,0x28,0x49,0x20,0x0 - YMTC 3dv3-128L TLC 16k 512Gb/CE 512Gb/die 4Plane/die
Bank27: 0x9b,0xc4,0x28,0x49,0x20,0x0 - YMTC 3dv3-128L TLC 16k 512Gb/CE 512Gb/die 4Plane/die
Bank33: 0x9b,0xc4,0x28,0x49,0x20,0x0 - YMTC 3dv3-128L TLC 16k 512Gb/CE 512Gb/die 4Plane/die
Bank35: 0x9b,0xc4,0x28,0x49,0x20,0x0 - YMTC 3dv3-128L TLC 16k 512Gb/CE 512Gb/die 4Plane/die
Bank41: 0x9b,0xc4,0x28,0x49,0x20,0x0 - YMTC 3dv3-128L TLC 16k 512Gb/CE 512Gb/die 4Plane/die
Bank43: 0x9b,0xc4,0x28,0x49,0x20,0x0 - YMTC 3dv3-128L TLC 16k 512Gb/CE 512Gb/die 4Plane/die
Bank49: 0x9b,0xc4,0x28,0x49,0x20,0x0 - YMTC 3dv3-128L TLC 16k 512Gb/CE 512Gb/die 4Plane/die
Bank51: 0x9b,0xc4,0x28,0x49,0x20,0x0 - YMTC 3dv3-128L TLC 16k 512Gb/CE 512Gb/die 4Plane/die
Bank57: 0x9b,0xc4,0x28,0x49,0x20,0x0 - YMTC 3dv3-128L TLC 16k 512Gb/CE 512Gb/die 4Plane/die
Bank59: 0x9b,0xc4,0x28,0x49,0x20,0x0 - YMTC 3dv3-128L TLC 16k 512Gb/CE 512Gb/die 4Plane/die
Flash params:
9b 16 00 00 | 7d 00 00 00 | 00 10 00 00 | 5a 00 ef 01
00 09 00 01 | 03 10 04 08 | 02 01 04 00 | 59 04 00 00
00 03 11 00 | 55 4c 03 08 | 00 00 00 00 | 00 00 00 00
..
00 00 00 00 | 00 00 00 00 | 14 00 00 00 | 00 00 00 00
00 20 00 00 | 00 00 00 00 | b0 04 b0 04 | 9a 02 02 00
00 00 33 2e | 32 2e 46 2e | 36 36 00 00 | 00 00 36 52
Page count        : 2304
Super blocks        : 495
Total Die        : 16
Channel            : 8
CE/Ch            : 2
Die/CE            : 1
Plane            : 4
Freq            : 1200/1200/666

Defects:
Bank00:    9
Bank01:    5
Bank02:    2
Bank03:    11
Bank04:    3
Bank05:    2
Bank06:    3
Bank07:    4
Bank08:    4
Bank09:    7
Bank10:    9
Bank11:    12
Bank12:    2
Bank13:    6
Bank14:    5
Bank15:    6
All:    90

Ganz schlau werde ich aus diesem Report offen gestanden nicht, zumindest finde ich keine Herstellerangaben bzgl. NAND.
 
Ganz schlau werde ich aus diesem Report offen gestanden nicht, zumindest finde ich keine Herstellerangaben bzgl. NAND.

In dem Report sind 16 Chips YMTC 3dv3-128L TLC 16k 512Gb ... gelistet. YMTC ist der einzige chinesische Hersteller von NAND Flash. Über dessen Qualität ist m. W. wenig bekannt. Woran man bei dem erkennt, dass das NAND für SSD qualifiziert ist, ist auch unklar. Bei westlichen Hersteller erkennt man das, sofern es sich nicht um Fälschungen handelt, i.d.R. an den Kennungen der Chips.
 
Ich muss mir den Text genauer anschauen später.

Von sinnlosen DD Befehl Benutzung halte ich nichts. Der einzig sinnvolle Einsatz ist die Erstellung eines bootbaren USB Sticks mit DD von einem ISO Image. Da macht es auch Sinn Sektorenweise zu schreiben. Fürs schreddern gibt es shred, für die Datensicherung ddrescue

Kleiner Tipp, es gibt da auch andere File Systeme. Dann kann man auch vom "eigentlich" schnelleren Arbeitsspeicher auf einen Datenträger schreiben.

Nur so als Beispiel, damit man nicht immer die automatischen Downloads löschen muss.
Code:
Sienna_Cichlid /home/roman # grep tmpfs /etc/fstab |grep Down
none            /home/roman/Downloads        tmpfs    size=50%,noatime,nofail,huge=always                                0 0

Eine "nackte" Partition auf einem Datenträger lege ich schon seit längerem nicht mehr an, bis auf Ausnahmesituationen. UEFI benötigt vfat als Beispiel.
Entweder LVM2 oder auch in Verbindung mit LUKS - wenn es sich um sensible bzw. sensibel und mobile Datenträger es sich handelt.

--

sollte diese Benchmarks in Gnu linux erstellt worden sein, fehlt die Angabe welches NTFS Modul verwendet wurde. Ich hatte Datenkorruption mit ntfs3 und bin auf das langzeitstabile ntfs-3g mit Fuse zurueck gewechselt.
 
Zuletzt bearbeitet:
für die Datensicherung ddrescue
Wer ddrescue für die Datensicherung nimmt, hat irgendwas nicht verstanden, denn ddrescue ist, wie der Name schon andeutet, für die Datenrettung. Bei der Datensicherung will man ja das alle Daten komplett und korrekt ins Backup geschrieben werden und ddrescue unterscheidet sich von dd ja vor allem darin, dass es eben auch bei nicht lesebaren Sektoren weitermacht, die Zieldatei ist dann allerdings korrupt und dies möchte man beim Backup nicht haben, da kopiert man dann sie lieber aus dem alten Backup zurück.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh