Impact of SSD Size on Cache Performance

A cache's performance is determined by how well the caching algorithm matches the workload, how well the cache size accommodates the workload and how quickly you can access the cache. So far we've demonstrated that Corsair's F40 can perform anywhere from noticeably worse to a bit faster than Intel's SSD 311 as a cache. I wanted to see if I could demonstrate the capacity advantage alone offered by the F40. To illustrate this I performed 11 tasks in a row composed of application launches, game launches and level loads. After running through all 11 tasks once, I rebooted and ran through them again. I then rebooted again and ran through the 11 tasks one more time, for a total of two cached runs per SSD cache. In theory the larger cache should be able to maintain application launch performance between runs:

Application Launch Performance - Seagate Barracuda 3TB - Time in Seconds
Application (Listed in Launch Order) First Run Intel SSD 311 - Run 1 Intel SSD 311 - Run 2 Corsair Force F40 - Run 1 Corsair Force F40 - Run 2
Portal 2 12.0 9.6 12.1 9.3 9.3
Portal 2 (Level Load) 17.1 14.8 15.4 14.1 14.2
WoW 5.3 4.3 5.8 4.7 4.4
WoW (Level Load) 11.9 11.7 6.2 5.2 5.2
Starcraft 2 15.3 11.9 10.2 7.9 8.0
Starcraft 2 (Level Load) 23.3 17.6 14.1 14.4 15.1
Photoshop CS5.5 7.1 3.5 6.5 6.3 3.2
After Effects CS5.5 19.3 6.6 11.6 12.7 6.7
Dreamweaver CS5.5 8.0 4.7 6.2 6.2 4.5
Illustrator CS5.5 6.1 2.9 3.7 5.3 3.1
Premier Pro CS5.5 10.4 3.2 3.1 6.9 3.2

Application Launch Test - Maximized Cache

On the first run both the Corsair F40 and Intel SSD 311 manage to perform very similarly. On the second run however, many of the applications load slower on the SSD 311 as some data has apparently been evicted from the cache. The 40GB Corsair F40 doesn't suffer the same fate as it has much more data for storage and as a result the second run through shows continued performance improvement.

AnandTech Storage Bench 2011 - Light Workload Final Words
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