The Intel SSD 910 Review
by Anand Lal Shimpi on August 9, 2012 1:00 PM EST- Posted in
- Storage
- SSDs
- Intel
- Intel SSD 910
The Test
For our tests we looked at combined performance of all two/four NAND partitions on the Intel SSD 910. We created a two/four drive RAID-0 array from all of the active controllers on the card to show aggregate performance. If you're going to dedicate one partition to each VM in a virtualized environment, you can expect performance to be roughly a quarter of what you see here per drive.
| CPU | Intel Core i7 2600K running at 3.4GHz (Turbo & EIST Disabled) |
| Motherboard: | Intel H67 Motherboard |
| Chipset: | Intel H67 |
| Chipset Drivers: | Intel 9.1.1.1015 + Intel RST 10.2 |
| Memory: | Qimonda DDR3-1333 4 x 1GB (7-7-7-20) |
| Video Card: | eVGA GeForce GTX 285 |
| Video Drivers: | NVIDIA ForceWare 190.38 64-bit |
| Desktop Resolution: | 1920 x 1200 |
| OS: | Windows 7 x64 |
Random Read/Write Speed
The four corners of SSD performance are as follows: random read, random write, sequential read and sequential write speed. Random accesses are generally small in size, while sequential accesses tend to be larger and thus we have the four Iometer tests we use in all of our reviews. For our enterprise suite we make a few changes to our usual tests.
Our first test writes 4KB in a completely random pattern over all LBAs on the drive (compared to an 8GB address space in our desktop reviews). We perform 32 concurrent IOs (compared to 3) and run the test until the drive being tested reaches its steady state. The results reported are in average MB/s over the entire time. We use both standard pseudo randomly generated data for each write as well as fully random data to show you both the maximum and minimum performance offered by SandForce based drives in these tests. The average performance of SF drives will likely be somewhere in between the two values for each drive you see in the graphs. For an understanding of why this matters, read our original SandForce article.
Intel was one of the first mainstream SSD vendors to prioritize random read performance, and it applies just as much to its enterprise offerings. The 800GB Intel SSD 910 delivers gobs of performance in our random read test. The 400GB version is also good but it's interesting to note Toshiba's 400GB 2.5" SAS drive does just as well here.
Random write performance is good, although still far away from what the SandForce based solutions from OCZ are able to deliver with compressible data. Throw anything other than pure text into your database however and Intel's drives become the fastest offerings once again.
Sequential Read/Write Speed
Similar to our other Enterprise Iometer tests, queue depths are much higher in our sequential benchmarks. To measure sequential performance I ran a 1 minute long 128KB sequential test over the entire span of the drive at a queue depth of 32. The results reported are in average MB/s over the entire test length.
Sequential read performance of the 800GB 910 is nearly 2GB/s and competitive with OCZ's 600GB Z-Drive R4. This is really where PCIe based SSDs shine, there's simply no way to push this much bandwidth over a single SATA/SAS port. The 400GB cuts performance in half but we're still talking about nearly 1GB/s. Of the single drives, Toshiba's 400GB SAS drive does the best at 521MB/s. Micron's P400e is a close second among 2.5" drives.
Here we finally see a difference between running the 800GB 910 in standard and high performance modes. In its max performance state the 800GB 910 is good for 1.5GB/s. OCZ's Z-Drive R4 is still a bit quicker with compressible data, but if you throw any incompressible (or encrypted) data at the drive performance is cut in half. Without the TDP cap removed, we can write sequentially to the 910 at 1GB/s.
Facebook
Twitter
RSS
39 Comments
View All Comments
Lazarus52980 - Thursday, August 9, 2012 - link
Wow, fantastic review. Thanks for the good work Anand.quiksilvr - Thursday, August 9, 2012 - link
Considering the hefty price on these devices, anything short of AES-256 in this day and age is unacceptable (yes I know you can do software encryption, but hardware accelerated is much more secure)prime2515103 - Thursday, August 9, 2012 - link
I'm confused. Isn't AES-256 the same whether it's done in hardware or software? I thought hardware encryption just performed better (encrypts/decrypts faster).Rick83 - Thursday, August 9, 2012 - link
AES-256 is no safer than AES-128, according to somewhat recent cryptanalysis on the algorithms.madmilk - Thursday, August 9, 2012 - link
Hardware acceleration is probably for performance, even AES-NI can't keep up with multiple PCIe SSDs.And yeah, AES-256 easier crack than AES-128 now. Not that it matters, with computational complexity still at what, 2^99?
It's much easier to just kidnap the sysadmin than attack crypto.
JPForums - Friday, August 10, 2012 - link
Since you didn't mention which attack you are referring to, I'm going out on a limb and assuming you are talking about the related key attacks on the full AES256 / AES192. I don't know of any other attacks that work on all 14 / 12 rounds. You should be aware that while such an attack is widely considered impractical, it isn't even possible under many circumstances. You need some up front data that you can't always get. To keep in relation to this article, I'll limit my scope to on the fly encryption software as it is closely related to the encryption implemented on this device. Several on the fly encryption packages are known to be immune to this kind of attack (I'll single out TrueCrypt as a popular open source package that isn't vulnerable to related key attacks). As long as you are using a properly programmed encryption package for your full disk encryption, AES-256 is still "more secure" than AES-128.
That said, if you actually calculated the amount of time it takes to brute force AES-128, you'll find that PCs and possibly humanity will have become a long forgotten relic of the past. Of course, processing power changes, but not that quickly. A bigger concern would be attacks that successfully bring the set of keys down to a manageable level. For this issue, diversity is probably more important than bit length, assuming the brute force key set is sufficiently large (I.E. 2^128).
Troff - Thursday, August 9, 2012 - link
I always end up needing to be able to communicate directly with each "drive", which is usually problematic through a raid controller and software raid is invariably faster and in every case I've tried so far much, much faster.Araemo - Thursday, August 9, 2012 - link
Isn't this necessary for trim anyways? If the OS can talk to each 'drive', trim should work, and performance will stay good, right?web2dot0 - Thursday, August 9, 2012 - link
Hey Anand,Shouldn't FusionIO cards be part of this comparison? It will most likely destroy the 910.
happycamperjack - Thursday, August 9, 2012 - link
http://hothardware.com/printarticle.aspx?articleid...Not according to this article. And ioDrive compared in this article is actually about 2x the price of either intel 910 or z-drive r4.