Random Read/Write Performance

Our random tests use Iometer to sprinkle random reads/writes across an 8GB space of the entire drive for 3 minutes, somewhat approximating the random workload a high end desktop/workstation would see. 

We present our default results at a queue depth of 3, as well as more stressful results at a queue depth of 32. The latter is necessary to really stress a four-way RAID 0 of SF-1200s, and also quite unrealistic for a desktop (more of a workstation/server workload at this point). 

We also use Iometer's standard pseudo random data for each request as well as fully random data to show the min and max performance for SandForce based drives. The type of performance you'll see really depends on the nature of the data you're writing. 

Iometer - 4KB Random Read

At best a single RevoDrive x2 (or four SF-1200 drives in RAID-0) can achieve over 500MB/s of 4KB random reads/writes. At worst? 286MB/s of random writes. 

Iometer - 4KB Random Write

Sequential Read/Write Performance

Our standard sequential tests write 128KB blocks to the drive, with a queue depth of 1, for 60 seconds straight. As was the case above, we present default as well as results with a 32 deep I/O queue. Pseudo random as well as fully random data is used to give us an idea of min and max performance.

Iometer - 128KB Sequential Read

The RevoDrive x2, like the IBIS, can read at up to 800MB/s. Write speed is an impressive 677MB/s. That's peak performance - worst case performance is down at 196MB/s for light workloads and 280MB/s for heavy ones. With SandForce so much of your performance is dependent on the type of data you're moving around. Highly compressible data won't find a better drive to live on, but data that's already in reduced form won't move around anywhere near as quickly.

Iometer - 128KB Sequential Write

The Test & Desktop Performance Garbage Collection & Final Words
Comments Locked


View All Comments

  • Out of Box Experience - Friday, November 5, 2010 - link

    Give us some Real-World numbers for a worst case scenario!

    Running Windows XP-SP2 on one of these with XP partitions (Not Aligned) and ZERO SSD Tweeks, how fast can these drives copy and paste 1GB of data with over 1000 files in at least 100 directories

    A vertex 2 can do it @ a meager 3.636MB / sec
    A 2.5 inch 5400RPM WD Laptop drive is FASTER than a Vertex 2 in this type of test
    A 7200RPM WD Desktop Drive is A LOT faster

    SSD's are still CRAP at copying and pasting uncompressible data around on the sasme drive that its stored on

    But they boot about as fast as my 300X Compact Flash

    Thats something I guess
  • extide - Monday, November 8, 2010 - link

    No, just the the drives optimally. Align it.

    That's like saying I am going to limit my HDD to PIO mode and bench it against another one in UDMA mode.

    Pretty much assinine, I mean you can even fix an unaligned partition and move an unaligned one from an HDD to an SSD and make it aligned. It's not very hard...
  • thanared - Friday, November 5, 2010 - link

    I don't know how Anand does his test... but I have 2 revo drive 240 gb in a stripe on an i7 based asus super computer and i get 1028 MBytes per second.

    I break the revo drive stripe, stripe in windows, and align the drive.
  • thanared - Friday, November 5, 2010 - link

    Sorry.. using Iomter, 1 worker, 32 outstanding i/o per target, 128k sequential
  • FH123 - Saturday, November 6, 2010 - link

    Anand, if you're investigating the real-world impact of the idle garbage collection bug, can you use a full-disk encryption product, such as Truecrypt? I believe even when you just initialise a TrueCrypt drive (the recommended slow version, not the quick), it fills every sector with random garbage for security purposes, which is presumably uncompressible. I suspect that, until such encryption products are written to interface with the TRIM command, they will cause you a real world problem right there and then, because they'll fill the disk with uncompressible data from the get-go. Remind us, do Sandforce implement full-drive encryption themselves, mitigating the need for programs like TrueCrypt when you want encryption?

    Something unrelated also springs to mind. You have previously slated Samsung SSDs for their relatively poor performance and - now I can't remember for sure, so correct me if I'm wrong - lack of TRIM. However I've read elsewhere that the later Samsung SSDs, e.g. since maybe a year ago or so, actually recognise when they are being formatted with an NTFS file system. This would theoretically allow them two things: (A) Automatically align the file system sector/cluster boundaries with SSD sectors and (B) Perform TRIM internally, because it understands NTFS and knows which sectors are empty. If true, then I think this is really quite smart. It avoids the need for TRIM altogether and should work across all Windows operating systems that use NTFS, even XP. The downside is, if Microsoft change NTFS in such a way as to break Samsung's understanding of it. That would, hypothetically, create an incompatibility with future Microsoft OSs.
  • x0rg - Tuesday, November 9, 2010 - link

    What if you just create a partition that is not using the full drive capacity, but 95%? would it help?

Log in

Don't have an account? Sign up now