Comparatif SSD : Intel, OCZ, Samsung, Silicon Power, SuperTalent

Publié le 08/09/2008 par
Imprimer
SuperTalent, Intel : des performances variables
Avant de passer aux performances pures, nous nous devons de revenir sur un point assez spécial que nous avons remarqué sur trois SSD, c'est-à-dire une baisse de performances dans certains cas au delà de la première utilisation.

Chez SuperTalent, ceci c’est produit lors de l’écriture sur le disque de fichiers de taille moyenne et réduite, sur les deux modèles. En effet, si l’écriture restait stable à 58 Mo /s et 38 Mo /s avec de gros fichiers sur les versions DX et MX, avec des fichiers moyens il en était tout autre : 28 Mo /s et 23 Mo /s à la première utilisation, puis 19.6 et 14.7 Mo /s à la seconde. Sur des petits fichiers, nous étions à 9.9 et 5.4 Mo /s au premier coup, puis 6.7 et 3.2 Mo /s ! Nous n’avons pas vraiment d’explication à fournir sur cet état de fait, d’autant que le problème n’a lieu que dans ce cas précis.

Mais le plus problématique ce situe au niveau du disque dur Intel, et il se limite également à l'écriture. Ce dernier affiche en effet des performances qui sont comme vous le verrez plus loin de très haut niveau. Seulement, ces dernières ont tendance à s’effondrer lors de certaines utilisations. C’est plus particulièrement le cas lorsque l’on attribue au disque une charge de type serveur entrainant des écritures aléatoires, mais pas seulement.

Ainsi, « neuf », le disque obtient le score impressionnant de 37 235 points à PC Mark Vantage pour la partie HDD. On peut relancer cet unique test plusieurs fois, le score est stable. Par contre, après remplissage du disque avec nos fichiers de tests utilisés lors de la copie, ce sur deux partitions ce qui fait qu’il est utilisé à quasiment 100%, on relance un PC Mark Vantage : 25 579 points.

Idem, si sur un disque neuf on lance notre test IOMeter, qui n’est lui-même pas très stable comme vous le verrez plus loin, puis PC Mark Vantage, on obtient 26 728 points. Pire, si derrière on refait notre test de copie de fichiers, et qu’ensuite on relance PC Mark Vantage, le score passe à 21 427. Après de multiples combinaisons nous avons même pu le faire tomber à 16 202 points – ce qui reste 2.5x un VelociRaptor. Par contre, le fait de ne faire que ce test ensuite permet de faire remonter petit à petit le score ... sans toutefois atteindre le niveau originel (22 000 points après 20 instances).

La copie de fichiers est également impactée par ces utilisations multiples, alors que ce test seul peut être effectué plusieurs fois avec les mêmes résultats. Ainsi, après avoir effectué sur un disque neuf divers PC Mark Vantage, copie de fichiers, et I/O Meter, on tombe à des résultats très bas : on passe de 70.4 à 43 Mo /s en écriture de gros fichiers, 47.2 à 12.7 Mo /s pour des fichiers moyens, 20.2 à 7.5 Mo /s pour des petits fichiers.

Cette perte de performances peut même atteindre des niveaux bien plus bas puisqu’à un moment nous sommes descendus à 6 Mo /s lors de l’écriture de gros fichiers. Il s’agit à priori d’un cas extrême, que nous n’avons pas réussi à reproduire une seconde fois. Il faut noter qu'au final, seule l'écriture semble réellement impactée par ce comportement. Voici pour representer le phénomène le graphique de débit h2bench (écriture séquentielle), dans un premier temps sur un disque nu, dans un second temps après que le disque ai fonctionné 30 minutes sous IOMeter avec des accès 100% aléatoires :


Intel explique cet état de fait ainsi :
SSDs all have what is known as an “Indirection System” – aka an LBA allocation table (similar to an OS file allocation table). LBAs are not typically stored in the same physical location each time they are written. If you write LBA 0, it may go to physical location 0, but if you write it again later, it may go to physical location 50, or 8.567 million, or wherever. Because of this, all SSDs performance will vary over time and settle to some steady state value. Our SSD dynamically adjusts to the incoming workload to get the optimum performance for the workload. This takes time. Other lower performing SSDs take less time as they have less complicated systems. HDDs take no time at all because their systems are fixed logical to physical systems, so their performance is immediately deterministic for any workload IOMeter throws at them.

The Intel ® Performance MLC SSD is architected to provide the optimal user experience for client PC applications, however, the performance SSD will adapt and optimize the SSD’s data location tables to obtain the best performance for any specific workload. This is done to provide the ultimate in a user experience, however provides occasional challenges in obtaining consistent benchmark testing results when changing from one specific benchmark to another, or in benchmark tests not running with sufficient time to allow stabilization. If any benchmark is run for sufficient time, the benchmark scores will eventually approach a steady state value, however, the time to reach such a steady state is heavily dependant on the previous usage case. Specifically, highly random heavy write workloads or periodic hot spot heavy write workloads (which appear random to the SSD) will condition the SSD into a state which is uncharacteristic of a client PC usage, and require longer usages in characteristic workloads before adapting to provide the expected performance.

When following a benchmark test or IOMeter workload that has put the drive into this state which is uncharacteristic of client usage, it will take significant usage time under the new workload conditions for the drive to adapt to the new workload, and therefore provide inconsistent (and likely low) benchmark results for that and possibly subsequent tests, and can occasionally cause extremely long latencies. The old HDD concept of defragmentation applies but in new ways. Standard windows defragmentation tools will not work.

SSD devices are not aware of the files written within, but are rather only aware of the Logical Block Addresses (LBAs) which contain valid data. Once data is written to a Logical Block Address (LBA), the SSD must now treat that data as valid user content and never throw it away, even after the host “deletes” the associated file. Today, there is no ATA protocol available to tell the SSDs that the LBAs from deleted files are no longer valid data. This fact, coupled with highly random write testing, leaves the drive in an extremely fragmented state which is optimized to provide the best performance possible for that random workload. Unfortunately, this state will not immediately result in characteristic user performance in client benchmarks such as PCMark Vantage, etc. without significant usage (writing) in typical client applications allowing the drive to adapt (defragment) back to a typical client usage condition.

In order to reset the state of the drive to a known state that will quickly adapt to new workloads for best performance, the SSD’s unused content needs to be defragmented. There are two methods which can accomplish this task.

One method is to use IOMeter to sequentially write content to the entire drive. This can be done by configuring IOMeter to perform a 1 second long sequential read test on the SSD drive with a blank NTFS partition installed on it. In this case, IOMeter will “Prepare” the drive for the read test by first filling all of the available space sequentially with an IOBW.tst file, before running the 1 second long read test. This is the most “user-like” method to accomplish the defragmentation process, as it fills all SSD LBAs with “valid user data” and causes the drive to quickly adapt for a typical client user workload.

An alternative method (faster) is to use a tool to perform a SECURE ERASE command on the drive. This command will release all of the user LBA locations internally in the drive and result in all of the NAND locations being reset to an erased state. This is equivalent to resetting the drive to the factory shipped condition, and will provide the optimum performance.
Vos réactions

Top articles