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).

We 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 (4K Aligned)

Random read speed has never been SandForce's strength and the Force GS is no exception. Real-time compression doesn't provide much benefit to read performance because reading from NAND has always been much faster than programming. Presumably SandForce's third generation controllers (SF-3000) will address random read and write performance, although it's way too early to tell how big of improvements we should expect.

Desktop Iometer—4KB Random Write (4K Aligned)—8GB LBA Space

Desktop Iometer—4KB Random Write (8GB LBA Space QD=32)

Random write performance is exceptionally low. At queue depth of 3 (the first random write graph), the Force GS manages to stay roughly on-par with other SF-2281 based SSDs, but at queue depth of 32 there is a more noticeable difference. While we are only talking about a difference of a few percents, it's still surprising that the Force GT doesn't achieve speeds similar to other SF-2281 SSDs.

Sequential Read/Write Speed

To measure sequential performance we ran a one 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 (4K Aligned)

Desktop Iometer—128KB Sequential Write (4K Aligned)

Sequential performance is typical SandForce. With highly compressible data, SandForce SSDs are still the fastest in sequential write speed, although OCZ Vertex 4 is getting very close.

Inside The Corsair Force GS and Test Setup AS-SSD Incompressible Sequential Performance
Comments Locked

56 Comments

View All Comments

  • Kristian Vättö - Friday, November 23, 2012 - link

    That is correct, Storage bench tests are run on a drive without a partition.

    Running tests on a drive with a partition vs without a partition is something I've discussed with other storage editors quite a bit and there isn't really an optimal way to test things. We prefer to test without a partition because that is the only way we can ensure that the OS doesn't cause any additional anomalies but that means the drive may behave slightly differently with a file system than what you see in our tests.
  • JellyRoll - Friday, November 23, 2012 - link

    Well personally I think that testing devices that are designed to operate in a certain environment is important. You are testing SSDs that are designed for a filesystem and TRIM, without a filesystem and TRIM. This means that the traces that you are running aren't indicative of real performance at all, the drives are functioning without the benefit of their most important aspect, TRIM. This explains why Anandtech is just now reporting the lack of TRIM support when other sites have been reporting this for months.
    Testing in an unrealistic environment with different datasets than those that are actually used when recording (your tools do not use the actual data, it uses substituted data that is highly compressible), in a TRIM free environment is like testing a Formula One car in a school zone.
    This is the problem with proprietary traces. Readers have absolutely no idea if these results are valid, and surprise, they are not!
  • extide - Saturday, November 24, 2012 - link

    The drive has NO IDEA id there is a partition on it or not. All the drive has to do is store data at a bunch of different addresses. That's it. Whether there is a partition or not has no difference, it's all just 0's and 1's to the drive.
  • JellyRoll - Saturday, November 24, 2012 - link

    it IS all ones and zeros my friend, but TRIM is a command issued by the Operating System. NOT the drive. This is why XP does not support TRIM for instance, and several older operating systems also do not support it. That is merely because they do not issue the TRIM command. The OS issues the TRIM commands, but only as a function of the file system that is managing it. :)
    No file system=no TRIM.
  • JellyRoll - Saturday, November 24, 2012 - link

    exceprts from the defiition of TRIM from WIKI:
    Because of the way that file systems typically handle delete operations, storage media (SSDs, but also traditional hard drives) generally do not know which sectors/pages are truly in use and which can be considered free space.
    Since a common SSD has no access to the file system structures, including the list of unused clusters, the storage medium remains unaware that the blocks have become available.
  • popej - Friday, November 23, 2012 - link

    Different drives, different algorithms and different results. But since you are testing drive well outside normal use you should draw conclusion with care, not all could be relevant to standard application.
  • R3dox - Friday, November 23, 2012 - link

    I've read everything (afaik) on AT on SSDs the past few years and the powersaving features used to be disabled in reviews. They, at least at some point, significantly affect performance. Back then I bought an Intel 80GB postville SSD and all tests I ran confirmed that these settings have quite a big impact.

    I currently have an Intel 520 (though sadly limited by a 3Gbps SATA controller on my old core i7 920 platform) and I never thought of turning everything on again, so I wonder whether the problem is solved with newer drives. Did I miss something or why aren't these settings disabled anymore? Hopefully it's not a feature of newer platforms.

    It would be nice if the next big SSD piece would cover this (or feel free to point me to an older one that does :)). I'd really like this to be clarified, if possible.
  • Bullwinkle J Moose - Friday, November 23, 2012 - link

    I was kinda wondering something similar

    AHCI might give you a sleight performance boost, but does it affect the "Consistency" of the test results having NCQ enabled or the power saving features of AHCI or the O.S. itself

    I always test my SSD's in the worst case scenario's to find bottom

    XP
    No Trim (Not even O&O Defrag Pro's manual Trim)
    Heavy Defragging to test reliability while still under return policy
    yank the drives power while running
    Stuff like that

    I predicted that my Vertex 2 would die if I ever updated the firmware as I have been tellyng people for the past few years and YES, it finally Died right after the firmware update

    It was still under warranty but I seriously do not want another one

    Time for me to thrash a Samsung 256GB 840 pro

    I feel sorry for it already
    Sniff
  • Bullwinkle J Moose - Friday, November 23, 2012 - link

    I forgot

    Misaligned partitions and firmware updates during the return policy will also be used for testing any of my new drives during the return policy

    I don't trust my data to a drive I haven't tested in a worst case scenario
  • Kristian Vättö - Friday, November 23, 2012 - link

    EIST and Turbo were disabled when we ran our tests on a Nehalem based platform (that was before AnandTech Storage Bench 2011) but have been enabled since that. Some of our older SSD reviews have a typo in the table which shows that those would be disabled in our current setup as well, but that's because Anand forget to remove those lines when updating the spec table for our Sandy Bridge build.

Log in

Don't have an account? Sign up now