Risultati: Tom's Hardware Storage Bench v1.0

Risultati: Tom's Hardware Storage Bench v1.0

Storage Bench v1.0

Storage Bench integra tutte le operazioni di I/O di una traccia registrata nel corso di due settimane. Ripetere questa sequenza serve a catturare le prestazioni in numeri intuitivi anche a un primo sguardo. Il tempo di idle viene cancellato, lasciando all'analisi solamente il tempo in cui ogni drive è impegnato con comandi host. Prendendo quel valore e l'ammontare dei dati scambiati durante la traccia, arriviamo a ottenere un data rate medio (in MB/s) che possiamo usare per confrontare i drive.

Non è un sistema perfetto. La traccia originale cattura il comando TRIM in transito, ma poiché è riprodotta su un drive senza un file system, TRIM non funzionerebbe nemmeno se fosse inviato durante il replay della traccia. Inoltre, eseguire i test con una traccia è un gran modo per catturare momenti dell'effettività attività di archiviazione, dandoci così dati complementari a quelli di Iometer.

Dati incomprimibili e Storage Bench v1.0

Degno di nota anche il fatto che il test della nostra traccia spinga il dato incomprimibile attraverso i buffer del sistema per far sì che il drive sia testato. Perciò, quando il replay della traccia riporta l'attività di scrittura, sta scrivendo dati ampiamente incomprimibili. Se eseguiamo un test simile su un SSD con controller SandForce, possiamo monitorare gli attributi SMART per avere un quadro un po' più chiaro.

Le letture host sono certamente superiori rispetto alle scritture host. È tutto all'interno della traccia. Con la compressione/deduplicazione inline di SandForce, vi aspettereste che la quantità d'informazione scritta verso la Flash fosse inferiore rispetto alle scritture host (salvo che il dato sia ampiamente incomprimibile, certamente). Per ogni gigabyte che l'host richiede siano scritti, il drive Mushkin è forzato a scrivere 1.05 GB.

Se il replay della nostra traccia fosse stato composto da scritture facilmente comprimibili che avrebbero cancellato il buffer, avremmo visto scritture verso la NAND come una frazione delle scritture host. Questo pone i drive testati su un piano più equo, nonostante la capacità del controller di comprimere dati al volo.

Velocità media

La traccia Storage Bench genera più di 140 GB di scritture durante il test e ovviamente tende a penalizzare le unità più piccole di 180 GB, mentre ricompensa quelle con una capacità di oltre 256 GB. Gli M500 non si comportano male in questo test, ma non riescono a offrire prestazioni spettacolari. L'M500 da 120 GB patisce per via della capacità, anche se non così severamente come l'SSD 525 di Intel da 30 GB. È persino più lento del Samsung 840 da 120 GB basato su memoria TLC.

Tutti gli M500 più capienti sono a metà gruppo. Ad esempio, il drive da 240 GB è 2,55 MB/s più lento dell'm4 di precedente generazione. Il modello da 960 GB è dietro al Plextor M5 Pro da 256 GB.

Il tempo di occupazione si accumula quando un SSD effettua un'operazione avviata dall'host. Quindi, quando il sistema operativo chiede all'unità di leggere e scrivere, i tempi di occupazione misurati lievitano. Prendete il tempo totale trascorso e la quantità di dati letti/scritti dalla traccia, e avrete il tempo di occupazione in un comprensibile dato in MB/s. Purtroppo, il tempo di occupazione e il numero in MB/s generato non sono il massimo per misurare le prestazioni con queue depth elevate.

Il test dice che gli M500 riescono a distinguersi gli uni dagli altri all'aumentare della queue depth. Questi SSD sono tuttavia fondamentalmente alla pari nell'affrontare le operazioni di I/O in background generate dalla maggior parte delle altre applicazioni mainstream di Windows, come la navigazione web. Solo quando abbiamo a che fare con un sacco di letture e scritture in un piccolo intervallo le unità di fascia media e alta si differenziano le une dalle altre. Per provare tutto questo, abbiamo bisogno di un altro test.