AnandTech Storage Bench 2011 - Light Workload

Our new light workload actually has more write operations than read operations. The split is as follows: 372,630 reads and 459,709 writes. The relatively close read/write ratio does better mimic a typical light workload (although even lighter workloads would be far more read centric).

The I/O breakdown is similar to the heavy workload at small IOs, however you'll notice that there are far fewer large IO transfers:

AnandTech Storage Bench 2011 - Light Workload IO Breakdown
IO Size % of Total
4KB 27%
16KB 8%
32KB 6%
64KB 5%

Despite the reduction in large IOs, over 60% of all operations are perfectly sequential. Average queue depth is a lighter 2.2029 IOs.

AnandTech Storage Bench 2011 - Light Workload

Our light workload doesn't do very well on the F40 at all. As we discovered in our launch review, the heavy workload runs for long enough (~3 hours) that performance doesn't change from run to run. Our light workload however only takes around 30 - 45 minutes to run and thus we see a significant performance difference from one run to the next (after 2 runs the performance gains level off though). While the Intel SSD 311 climbs significantly in both runs, the F40 shows a marginal improvement in the first run and tops out at around 80MB/s regardless of what HDD it's paired with. Clearly we're hitting a bottleneck here, one that doesn't exist on the 311.

An obvious benefit of Intel's SSD 311 is that its firmware was designed with caching in mind, something that isn't true for standard SSDs used as a cache.

AnandTech Storage Bench 2011 - Light Workload

AnandTech Storage Bench 2011 - Light Workload

AnandTech Storage Bench 2011 - Light Workload

AnandTech Storage Bench 2011 - Light Workload

AnandTech Storage Bench 2011 - Light Workload

AnandTech Storage Bench 2011 - Heavy Workload Impact of SSD Size on Cache Performance
Comments Locked

81 Comments

View All Comments

  • iwod - Friday, May 13, 2011 - link

    If 20GB is really what most of us do use. What happen when you have 8GB x 4 RAM? With Windows 7 Superfetch, most of your data will be fetched inside memory.

    And with $110, would i be better off with a RAM drive, and fake that as a drive for use with Intel SRT?
  • Araemo - Friday, May 13, 2011 - link

    Since this SSD caching is software-driven.. it doesn't help any with boot performance (Until the service is running anyways), right?
  • Stahn Aileron - Friday, May 13, 2011 - link

    I'm pretty sure it's built into the chipset's RAID BIOS/firmware, not used at the OS-level. The OS-level stuff is probably more for management and monitoring than anything else.

    If fact, I think you have to set it up in the BIOS/firmware, not within the OS. I'd have to look at the Z68 review again to be sure about the wording though.
  • cbass64 - Friday, May 13, 2011 - link

    In the last SRT review (http://www.anandtech.com/show/4329/intel-z68-chips... a 3TB drive took 55+ seconds to boot and a 3TB drive with SRT booted in 33 seconds...
  • micksh - Friday, May 13, 2011 - link

    Can you do TRIM on cache SSD?

    I expect that SSD performance would degrade over time regardless of whether it's a cache or standalone drive.
    It looks like this aspect has been missed in original Z68 review as well.
  • Stahn Aileron - Friday, May 13, 2011 - link

    Out of curiosity, does Intel's SRT and RAID drivers support TRIM-command passthrough? I believe it was mentioned that SRT only works with the chipset in RAID mode. Last I recall, no RAID drivers support TRIM yet (I might be out of the loop.)

    Also, in a somewhat related matter: Have you considered looking at SRT's affect on an SSD's long-term read/write capability? I don't think it'll matter TOO much if someone is using a dedicated SSD for the cache. I'm asking this in the scenario that a user has a large capacity SSD (say 160GB) and allocates part of it (say 20GB - 40GB) as a cache while the rest is used for something else. So, for example:

    120GB = OS install and frequently use programs/applications (Office, Adobe, etc.)
    40GB = Cache for larger storage volume meant for infrequently used or very large installation size apps/programs (like a gaming drive/partition/volume.)

    I think the above example may be what many power users/enthusiasts will want to do. Would this have an affect on an SSD's long-term read/write performance? Especially in relation to the support of TRIM with Intel's SRT/RAID drivers. Or will the garbage collection algorithm be the only thing available to maintain it performance in the long run? Do users have to start looking at the garbage collection performance of an SSD as well when choosing one to use as a cache? Or has Intel devised a RAID driver for the Z68 that supports TRIM?

    Oh, and would my above usage scenario (splitting and sharing of the SSD) affect data eviction/retention for the cache in any noticeable way, if at all?
  • micksh - Friday, May 13, 2011 - link

    RAID drivers support TRIM. Just one condition - SSD has to be a single drive in order TRIM to work. If RAID is made of SSDs TRIM won't work, but you han have HDD RAID and single SSD with TRIM on the same controller.

    SRT is different from RAID so the question is still valid. And your scenario is very interesting too.

    I think it's believed that SLC SSDs don't need TRIM. I don't even know if 311 supports it. Intel might not even bother with adding TRIM to SRT if 311 is its main usage target, I'm not sure.
    But if you are going to use your own MLC drive it is important.

    And yes, defragmentation from the next post is also important question.
  • Stahn Aileron - Friday, May 13, 2011 - link

    All flash NAND can use TRIM. Lack of it for SLC just has a lower overhead penalty on (re)write performance than it does for MLC. Though you did remind me that Intel Gen 1 (50nm) SLC SSD, the X25-E, never got TRIM support, far as I recall.

    I didn't realize RAID drivers allowed TRIM passthrough on single drives. I always thought SSDs had to be on ACHI-mode drivers to support TRIM properly, regardless of configuration. I wonder if/when they will fix it for RAID arrays, then?

    Lastly, yeah, forgot about the fragmentation problem as well. I wonder if Intel's SRT caching algorithm is smart enough to ignore defrag activity?

    Actually, I have been curious as to what Diskeeper's SSD-related feature actually does for an SSD. I own a copy of DK with HyperFAST and I've been wondering what it does for quite some time now. Otherwise, I've been using DK for a long time now (since '05, at least).

    Anand, have you ever looked at DK's impact on SSD performance? Or at least find out it role and what it actually DOES on a system?
  • Henk Poley - Monday, May 16, 2011 - link

    HyperFast does not much at all. At best it caches some writes, that can improve SSDs that lack in the 4k write department (old disks). I also read it helps with file consolidation, which can help an OS/SSD without TRIM (old disks). Never used space can be used for write leveling by the SSD. Real world benchmarks appear to find nothing changes or that the performance slightly deteriorates.

    The product was built when 8GB PATA SSDs were pretty nifty.

    Besides all that, if you can write less to an SSD, that is in general better. So don't move files around willy nilly (don't defrag).
  • Dribble - Friday, May 13, 2011 - link

    So I have my big HD that obviously needs regularly defragged attached to my SSD.

    How do I get the defragger to not wear out the SSD?

Log in

Don't have an account? Sign up now