How do we test?

Testenvironment

We recommend that readers who aren't interested in test procedures jump over this page and head directly to the test results.

Models
ADATA S511 60 GB
ADATA S511 SSD 120 GB
ADATA XPG mSATA SSD SX300 128 GB
Corsair F100 100 GB
Corsair Force 3 120 GB
Corsair Force GS 240 GB
Corsair Force GT 120 GB
Corsair Neutron GTX 240 GB
Corsair P128 128 GB
Corsair X128 128 GB
Crucial M500 480 GB
Extrememory XLR8 Express 120 GB
Intel SSD 335 Series 240 GB
Intel SSD 520 180 GB
Intel SSD 520 240 GB
Intel X25-E 32 GB SLC
Intel X25-M 80 GB
Intel X25-M Gen2 34nm 160 GB
Intel X25-M Gen2 34nm 160 GB Raid0
Intel X25-M Gen2 34nm 160 GB Raid0 (Full)
Kingmax SMP35 Client 240 GB	n/A
Kingston HyperX SSD 120 GB
Kingston HyperX 3K SSD 120 GB
Kingston HyperX SSD 240 GB
Kingston SSDNow V+ 64 GB
Kingston SSDNow V+ 200 90 GB
Kingston SSDNow VSeries 40 GB
OCZ Agility 120 GB (v. 1.3)	nA
OCZ Agility 3 240 GB
OCZ Agility 4 256 GB
OCZ Apex 120 GB	n/A
OCZ Technology Core V2 60 GB	n/A
OCZ IBIS 240 GB
OCZ Octane 512 GB
OCZ Octane 1 TB
OCZ RevoDrive 3 240 GB
OCZ RevoDrive 3 X2 480 GB PCIe-SSD
OCZ RevoDrive X2 480 GB PCIe-SSD
OCZ RevoDrive Hybrid 120GB SSD, 1TB HDD
OCZ Synapse 64 GB
OCZ Vector 256 GB
OCZ Vertex 120 GB	n/A
OCZ Vertex 120 GB (v 1.5)	n/A
OCZ Vertex 120 GB (v 1.5) (Full)	n/A
OCZ Vertex 3 240 GB
OCZ Vertex 3.20 120 GB
OCZ Vertex 3.20 240 GB
OCZ Vertex 4 256 GB
OCZ Vertex 4 256 GB Firmware 1.4RC
OCZ Vertex 4 256 GB Firmware 1.5
OCZ Vertex 4 512 GB
OCZ Vertex 4 512 GB Firmware 1.4RC
Photofast G-Monster 120 GB V2	n/A
Samsung SSD PM800 64GB (VBM18C1Q)	n/A
Samsung SSD PM800 256 GB (VBM19C1Q)	n/A
Samsung SSD PM800 256 GB (VBM18C1Q)	n/A
Samsung PM830 SSD 128 GB
Samsung PM830 SSD 256 GB
Samsung PM840Pro 256 GB
SanDisk Extreme SSD 120 GB
SanDisk Extreme SSD 240 GB
Toshiba THNSNF512GCSS 512 GB	n/A
Testenvironment
Motherboard	ASUS P8P67 Deluxe B3
Chipset	Intel P67	1'333 MHz
CPU	Intel Core i7 2600k	3.4 GHz
Memory	Kingston HyperX 2133	4 GByte
Graphics card	Gigabyte GeForce GTX 285
Storage (system)	Seagate Barracuda	640 GB
Operating systems	Ubuntu - most recent Kernel version Windows 7 64 Bit with caching drives
Filesystem	XFS

We think everybody reading this article can imagine the following scenario: You just bought a hard drive which according the specs sheet should transfer 120 MByte/s reading and writing. In the reviews you read about astonishing 110 MByte/s but after you put the drive into you system it feels much slower. The whole story gets even worse when you start a benchmark which does randomread/write of 4 KByte blocks. There you only get two to three MBytes/s.

Because of this we don't want to publish screenshots of standard programs like HD-Tach, HD-Tune, ... we want our tests to be

• reproducible,
• accurate
• meaningful and
• varied ...

... sind.

We test with activated caches and NCQ (Native Command Queueing) because they're also activated under daily use. But the data size tested is always at least twice the amount of the memory. In this there will be no intereference.

We noticed that the measuring error is constantly within ±2%. Therefore we mention it only here.

Additionally we evaluate the S.M.A.R.T. data to assess if there are already errors.

The following table give you a brief overview to which points we turn our centre of attention.

Test	Observations
Sequential Read/Write Tests	Are the values within the specifications? Which influence has the block size? Which influence has the filesystems block size?
Random Read/Write Tests	How severe is the influence on the theoretically possible (sequential) datarate? Which influence has the block size? Which influence has the block size on the filesystem?

iozone3

iozone3 is a benchmark suit for storage solutions which natively runs under Linux.

Therefore we are testing the throughput with different block sizes using the following commands:

KByte/s

• iozone -Rb test4k.xls -i0 -i1 -i2 -+n -r 4k -s4g -t32
• iozone -Rb test16k.xls -i0 -i1 -i2 -+n -r 16k -s4g -t32
• iozone -Rb test32k.xls -i0 -i1 -i2 -+n -r 32k -s4g -t32
• iozone -Rb test64k.xls -i0 -i1 -i2 -+n -r 64k -s4g -t32
• iozone -Rb test128k.xls -i0 -i1 -i2 -+n -r 128k -s4g -t32
• iozone -Rb test256k.xls -i0 -i1 -i2 -+n -r 256k -s4g -t32

iops

• iozone -Rb test4ko.xls -i0 -i1 -i2 -+n -r 4k -s4g -t32 -O
• iozone -Rb test16ko.xls -i0 -i1 -i2 -+n -r 16k -s4g -t32 -O
• iozone -Rb test32ko.xls -i0 -i1 -i2 -+n -r 32k -s4g -t32 -O
• iozone -Rb test64ko.xls -i0 -i1 -i2 -+n -r 64k -s4g -t32 -O
• iozone -Rb test96ko.xls -i0 -i1 -i2 -+n -r 96k -s4g -t32 -O
• iozone -Rb test128ko.xls -i0 -i1 -i2 -+n -r 128k -s4g -t32 -O

 

Why do we test different block sizes?

It is important to reproduce scenarios of daily usage. Certain parameters need to be variable during the test to make a statement about the product. In our test the parameters are the different block sizes. It defines the size in KBytes which is written/read on the drive during a transaction.

With this method one can test the reading and writing of either small and big files. In a normal personal computer environment you usually don't find many files smaller than 16 KByte. The relative amount of small files is much bigger on a mail or database server. Therefore tests with small block sizes are of interest for database-based applications.

In bigger RAID arrays the hard disk cache is usually disabled and the RAID-Controller takes over the job of caching. Exactly in such setups hard drives need to be very fast when reading or writing small amounts of data. Sequential throughput isn't interesting in this case.

Page 1 - Introduction / Specs	Page 7 - Random read KByte/s
Page 2 - Impressions	Page 8 - Sequential write ops
Page 3 - How do we test?	Page 9 - Sequential read ops
Page 4 - Sequential write KByte/s	Page 10 - Random write ops
Page 5 - Sequential read KByte/s	Page 11 - Random read ops
Page 6 - Random write KByte/s	Page 12 - Conclusion

Discuss this article in the forum