Still Resilient After Truly Random Writes

In our Agility 2 review I did what you all asked: used a newer build of Iometer to not only write data in a random pattern, but write data comprised of truly random bits in an effort to defeat SandForce’s data deduplication/compression algorithms. What we saw was a dramatic reduction in performance:

Iometer Performance Comparison - 4K Aligned, 4KB Random Write Speed
  Normal Data Random Data % of Max Perf
Corsair Force 100GB (SF-1200 MLC) 164.6 MB/s 122.5 MB/s 74.4%
OCZ Agility 2 100GB (SF-1200 MLC) 44.2 MB/s 46.3 MB/s 105%

 

Iometer Performance Comparison
Corsair Force 100GB (SF-1200 MLC) Normal Data Random Data % of Max Perf
4KB Random Read 52.1 MB/s 42.8 MB/s 82.1%
2MB Sequential Read 265.2 MB/s 212.4 MB/s 80.1%
2MB Sequential Write 251.7 MB/s 144.4 MB/s 57.4%

While I don’t believe that’s representative of what most desktop users would see, it does give us a range of performance we can expect from these drives. It also gave me another idea.

To test the effectiveness and operation of TRIM I usually write a large amount of data to random LBAs on the drive for a long period of time. I then perform a sequential write across the entire drive and measure performance. I then TRIM the entire drive, and measure performance again. In the case of SandForce drives, if the applications I’m using to write randomly and sequentially are using data that’s easily compressible then the test isn’t that valuable. Luckily with our new build of Iometer I had a way to really test how much of a performance reduction we can expect over time with a SandForce drive.

I used Iometer to randomly write randomly generated 4KB data over the entire LBA range of the Vertex 2 drive for 20 minutes. I then used Iometer to sequentially write randomly generated data over the entire LBA range of the drive. At this point all LBAs should be touched, both as far as the user is concerned and as far as the NAND is concerned. We actually wrote at least as much data as we set out to write on the drive at this point.

Using HDTach, I measured performance across the entire drive:

The sequential read test is reading back our highly random data we wrote all over the drive, which you’ll note takes a definite performance hit.

Performance is still respectably high and if you look at write speed, there are no painful blips that would result in a pause or stutter during normal usage. In fact, despite the unrealistic workload, the drive proves to be quite resilient.

TRIMing all LBAs restores performance to new:

The takeaway? While SandForce’s controllers aren’t immune to performance degradation over time, we’re still talking about speeds over 100MB/s even in the worst case scenario and with TRIM the drive bounces back immediately.

I’m quickly gaining confidence in these drives. It’s just a matter of whether or not they hold up over time at this point.

The Test

With the differences out of the way, the rest of the story is pretty well known by now. The Vertex 2 gives you a definite edge in small file random write performance, and maintains the already high standards of SandForce drives everywhere else.

The real world impact of the high small file random write performance is negligible for a desktop user. I’d go so far as to argue that we’ve reached the point of diminishing returns to boosting small file random write speed for the majority of desktop users. It won’t be long before we’ll have to start thinking of new workloads to really start stressing these drives.

I've trimmed down some of our charts, but as always if you want a full rundown of how these SSDs compare against one another be sure to use our performance comparison tool: Bench.

CPU Intel Core i7 965 running at 3.2GHz (Turbo & EIST Disabled)
Motherboard: Intel DX58SO (Intel X58)
Chipset: Intel X58 + Marvell SATA 6Gbps PCIe
Chipset Drivers: Intel 9.1.1.1015 + Intel IMSM 8.9
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
Starting with the Differences: Power Consumption Sequential Read/Write Speed
Comments Locked

44 Comments

View All Comments

  • marraco - Thursday, April 29, 2010 - link

    The data compression accelerates the writing speed, but, the question is:

    The OS still considers that the non written space is occupied?

    Or the compression releases the non used space?

    I suspect that the unused space is marked anyways as used space, but I would like a confirmation.
  • TheHolmes - Thursday, April 29, 2010 - link

    If Sandforce is largely about writing fewer bits to the NAND flash, wouldn't it also follow that turning on OS level compression would also work as well?

    Also, I'd be interested to know if using OS striping is ok with TRIM, as there aren't any controllers out there that work with TRIM when SSDs are striped.
  • cyrexo - Friday, April 30, 2010 - link

    Hey Anand,

    have you put a Sandforce based disk into a mabook and let it running only on OSX?

    Can you say something about speeddrops without Trim or does the build in "gc" wich isn't "gc" can handle it accurate?

    i get my hands on a new I7 macbook and want to put a sdd into but i don't know if i should go for the old intels, use the new sandforce or wait some moths to see what intel does and how stable sandforce is without trim.
  • 529th - Tuesday, September 28, 2010 - link

    What is the verdict with these Vertex 2 100g SSD drives???

    Because I just got one in the mail from OCZ as a replacement for my dead Vertex LE 100G SF1500

    Anand, care to comment as they have been in your desktop for ~ 5 months now.. or anyone who owns one???

    Thanks,

    529th

    p.s. i am considering a main rig install with this, booting out my ever reliable 150g 1st gen Raptor...

Log in

Don't have an account? Sign up now