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.

Our first test writes 4KB in a completely random pattern over an 8GB space of the drive to simulate the sort of random access that you'd see on an OS drive (even this is more stressful than a normal desktop user would see). I perform three concurrent IOs and run the test for 3 minutes. 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.

Desktop Iometer - 4KB Random Read

Desktop Iometer - 4KB Random Write

Desktop Iometer - 4KB Random Write (QD=32)

Random speeds are slightly down from SSD 520/525. The decrease could be NAND related as it's a fact that read and program times go up as we move to smaller lithographies, which will then translate to decrease in overall performance. However, compared to the SSD 335 performance is better but we're dealing with a higher bin of IMFT's 20nm NAND, so that's not a surprise. 

Sequential Read/Write Speed

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 1. The results reported are in average MB/s over the entire test length.

Desktop Iometer - 128KB Sequential Read

Read performance has never been one of SandForce's biggest strengths but write performance is top of the class (except when dealing with incompressible data).

Desktop Iometer - 128KB Sequential Write

 

AS-SSD Incompressible Sequential Read/Write Performance

The AS-SSD sequential benchmark uses incompressible data for all of its transfers. The result is a pretty big reduction in sequential write speed on SandForce based controllers.

Incompressible Sequential Read Performance

Incompressible Sequential Write Performance

AnandTech Storage Bench 2013 Performance vs Transfer Size
Comments Locked

60 Comments

View All Comments

  • HisDivineOrder - Saturday, November 16, 2013 - link

    Remember when Sandforce used to be desired? That was a long, long time ago. Now they stink of bad firmwares and ugly compromise.
  • jwcalla - Saturday, November 16, 2013 - link

    I'm surprised we haven't seen a new gen from them yet. I wonder if they're even working on anything.
  • purerice - Sunday, November 17, 2013 - link

    True. It is a better problem to have than great firmware with bad hardware though. I mean, if they have the desire, they can fix existing drives. If they don't, they'll just lose customers, end of story.
  • GuizmoPhil - Sunday, November 17, 2013 - link

    The mITX ASUS Maximus VI Impact also got an M2 slot.
  • g00ey - Sunday, November 17, 2013 - link

    Sorry but just I don't believe in PCIe as a viable interface for SSD storage. If SATA 6 Gbps turns out to be a bottleneck then make drives that use two SATA channels or more. Or even switch to SAS 12Gbbs which was introduced back in 2011. Not many changes will be needed when switching to SAS since SAS is pin-compatible with SATA and a SAS controller can run SATA drives. The only noticeable difference is that SAS is more stable and cable lengths up to 10 meters (33 feet) are possible whereas only 1 meter (3.3 feet) works for SATA. I also like the SFF-8087/8088 connectors which house 4 SAS/SATA channels in one connector, there is both an internal version (SFF-8087) and an external version (SFF-8088) of this connector, just like SATA vs eSATA.

    The major advantages of SAS/SATA over PCIe is spelled RAID and hot-swap so it only makes sense to implement PCIe based storage in ultra-portable applications and applications with extremely high demands on low-latency.
  • tygrus - Sunday, November 17, 2013 - link

    How do the SSD's perform with a simultaneous mix of Read/Write ? eg. 70/30 mix of random R/W with Q=32 or simulate tasks that stream read-modify-write.
  • emvonline - Sunday, November 17, 2013 - link

    Couple items: The real difference with the 530 is low power options from Sandforce controller and potentially lower cost 20nm NAND. If it isnt cheaper than 520, don't buy it.

    Intel chose 2281 controller for its consumers SSDs over its internal controller. Why would you recommend that Intel do a consumer SSD with its internal controller? Intels 3500 internal controller is purchased from and fab'd by another company anyway. Do you think the performance it much better than Sandforce 2281 B2?
  • 'nar - Monday, November 18, 2013 - link

    I must be dense, because I still don't get why you criticize Sandforce so much about incompressible data. I don't see a need to put incompressible data on an SSD in the first place, so the argument is meaningless.

    For cost per GB of storage, most people still do not want SSD's holding 500GB of data. Why do they have over 500GB? Pictures, music, movies, ie incompressible data. Therefore, that is stored on a much more cost-effective hard drive and hence, irrelevant here.

    I don't see a performance advantage either. What do you do with music and movies? Play them. How much speed does that require? 12MBps? Hard drives are fine for media servers. Maybe you want to copy to a flash drive, but it will be limited itself to about 150MBps for good USB 3 drives anyway. And if you are editing video often then you are likely going over that 20GB per day of writes, so you should put that on an enterprise scratch disk anyway.

    So, you ask if Sandforce will "fix" this problem? What problem? It is the fundamental design feature they have. It is what makes them unique, and in "normal" system it is quite useful, reviewers looking for bigger sledge hammers not withstanding. That's like saying the president is not so bad, but maybe if he weren't so black.

    You can break anything. These are not build to be indestructible, nobody would be able to afford them if they were. These are built for common use, and I do not see hammering incompressible data in these benchmarks a common use.
  • Kristian Vättö - Tuesday, November 19, 2013 - link

    If you're using software based encryption, it's quite a big deal because all your data will be incompressible. For other SSDs it's the one and same whether the data is compressible or not, but for SandForce based SSDs it's not, so it's a thing worth mentioning. What would be the point of reviews in the first place if we couldn't point out differences and potential design flaws?
  • 'nar - Thursday, November 21, 2013 - link

    noted. That's it. Not half of all benchmarks. I don't use software encryption for most of my data.

Log in

Don't have an account? Sign up now