Es betrifft nicht nur die ganz kleinen Dateien, auch die grösseren werden ja nicht immer optimal über alle Kanäle verteilt, denn der Controller muss ja auch die gleichmäßige Nutzung der NANDs berücksichtigen (Wearleveling) und die bei 8 Kanäle muss die Datei ja mindestens 32k groß sein, um in besten Fall überhaupt auf alle 8 Kanäle verteilt zu werden.
So groß ist der Unterschied zwischen einem MB und einem GB aber nicht. Der Overhead spielt schon eine Rolle, denn wenn Windows eine Datei liest, so werden immer erstmal die logischen Adressen (LBAs) ermittelt, auf denen diese liegt. Dann liest der Treiber davon mit einem Befehl so viele hintereinander ein, wie in seinen Puffer passen bzw. in einem Fragment vorliegen (ja, auch bei SSDs kostet Fragmentierung wegen des Overheads Performance, wenn auch nur minimal, aber die Kosten der Defragmentierung stehen in keinem Verhältnis zum Nutzen). Du kannst also nicht einfach eine beliebige 1MB Datei mit einer beliebigen 1GB Datei vergleichen.
Wenn Du einen Bechmarks nimmst, dann musst Du außerdem beachten, dass diese oft alt sind und auch HDD Zeiten stammen, wo man dann einfach irgendwelche LBAs liest, egal ob diese belegt sind oder nicht. Bei HDDs werden die LBAs fest auf Kopf, Zylinder und Sektor umgerecht und daher funktioniert das, aber SSDs mappen die LBAs dynamisch auf Flashadressen und können für unbeschriebene LBAs daher keine sinnvollen Daten liefern. Die lesen also nichts aus dem Flash sondern antworten einfach mit Nullen oder unsinnigen Daten, wobei nur das Interface die Geschwindigkeit limitiert.
Das passiert z.B. bei HDTach und HDTune gerne, wie man bei
diesem Test einer Intel X-25V bei awardfabrik.de sieht:
bzw.
Die SSD kann gar keine 200MB/s oder gar mehr lesen, die Kurven zeigen nur da die reale Geschwindigkeit halbwegs richtig an, wo der Speicher auch wirklich belegt ist. CrystalDiskMark zeigt wie schnell die lesen kann, wenn man auch wirklich Daten zum Lesen hineingeschrieben hat:
