SSD RAID 0 Performance Over Time Project

[Gollan]

A common concern about SSD RAID is the lack of TRIM support possibly degrading performance over time. I will be monitoring my Intel 510 120 GB SSD RAID 0 array to see how it performs over time. Here is the first update.


SSD RAID 0 Write-back Cache ON Composite 1 Week

The only significant change is a 7% decrease in sequential read performance. Since lack of TRIM is expected to impact write performance, I'm not sure what to make of it. I did add another SSD to my system, but on the SATA 3.0 GB/s port.

I discovered that by using the Intel SSD Toolbox, I can view SMART info for each drive. This will allow me to track host writes for the two drives in the array:

2011-09-23 Host writes: 17 GB and 419 GB
2011-09-30 Host writes: 302 GB and 737 GB

The large increase in host writes reflects a new Windows installation gaining it's full complement of software. The User folder is kept on a separate hard drive and this week I moved Steam and my other games onto a separate SSD (a new Corsair F120 replaced in an RMA).

This system doesn't idle. It is either on and in use or it is off. After I collect a few weeks of performance data, I plan to let it idle logged off for a few hours to see if the SSD's "garbage collection" feature can be detected.

I welcome your comments or questions.

[Octavean]

Before I setup my first SSD RAID 0 array I did some research and found that there may be a way to manually TRIM an SSD. Not sure if it is applicable to an actual RAID array but it might be worth looking into. Personally I stopped worrying about the “possible” loss of performance as it always seems fast to me.

You can do a Google search on “Tony TRIM” to get a feel for how people have used the technique outlined here:

http://www.ocztechnologyforum.com/fo...-not-need-this

According to the guide you should take note that “Perfectdisk10 is safe for use with SSD as is Diskeeper”.

I used the Kingston SSD models from this review (same controller) in my RAID 0 array:

TRIM
I don't have and pretty charts or graphs to explain this next part, but I will share an observation I made during my fragmentation testing. When running my fragmentation tool, I observe IOPS drop as the drive becomes more and more overloaded with the task of tracking the random writes taking place. Here the JMicron controller behaved like all other drives, but where it differed is what happened after the test was stopped. While most other drives will stick at the lower IOPS value until either sequentially written, TRIMmed, or Secure Erased, the JMicron controller would take the soonest available idle time to quickly and aggressively perform internal garbage collection. I could stop my tool, give the drive a minute or so to catch its breath. Upon restarting the tool, this drive would start right back up at it's pre-fragmented IOPS value.

Because of this super-fast IOPS restoring action, and along with the negligible drop in sequential transfer speeds from a 'clean' to 'dirty' drive, it was impossible to evaluate if this drive properly implemented ATA TRIM. Don't take this as a bad thing, as any drive that can bring itself back to full speed without TRIM is fine by me, even if that 'full speed performance' is not the greatest.

This type of self-healing (i.e. without needing TRIM) is great for those wanting to run a few SSD's behind a RAID, since no RAID implementation is currently capable of passing TRIM from the OS to the arrayed SSD's. Better yet, considering this drive is tailored to the budget crowd who may very well still be running XP or Vista, it's good to have a few choices that don't require TRIM to maintain decent levels or performance.

http://www.pcper.com/reviews/Storage...-Appearance/Fr

So again I’m not terribly worried about performance degradation due to the lack of TRIM support in a RAID array.

[richardd43]

You can do a Google search on “Tony TRIM” to get a feel for how people have used the technique outlined here:

I have been using this method since Tony wrote it and have never had a problem with it.

I currently have 3 Corsair SSDs in raid 0 and they still perform like new.

[Octavean]

I have been using this method since Tony wrote it and have never had a problem with it.

I currently have 3 Corsair SSDs in raid 0 and they still perform like new.

Testify!!!

[richardd43]

Testify!!!

Not exactly sure what you are asking

[Octavean]

Not exactly sure what you are asking

I’m sort of kidding here,…

But its basically a reference to user “testimonials” with respect to, in this case, something that works for the task at hand. Its good to hear someone with an SSD RAID 0 array able to confirm that the “Tony Trim” process works.

[Gollan]

So again I’m not terribly worried about performance degradation due to the lack of TRIM support in a RAID array.

It is an interesting article and makes sense. I'm not particularly concerned about big performance loss. My project is aimed at quantifying any performance loss. If I find some, I will look at the benefits of remedies such as letting the computer idle, consolidating free space, and large sequential writes to the drive.

[Gollan]

SSD RAID 0 Write-back Cache ON Composite 2 Weeks

The second week of data collection and we see another drop in sequential read performance in the benchmark. It is now 11% slower than when the RAID 0 array was fresh. This is not the result I was expecting - which is always very exciting!

I can also update my host writes chart:

2011-09-23 Host writes: 17 GB and 419 GB
2011-09-30 Host writes: 302 GB and 737 GB
2011-10-07 Host writes: 356 GB and 793 GB

Much less data was written in the second week as I was away for a few days and I just stopped adding new software! I received my Corsair F120 back from RMA, which I installed on one of the SATA 3.0 GB/s connectors. I'm using it for games.

ETA:
Some graphs of Sequential Read against a couple of possible candidates for dependency:


SSD RAID 0 Write-back Cache ON Graphs 2 Weeks

It's too early to tell what we have, but still fun to look at the graphs!

As always, I welcome your questions and comments!

[Gollan]

SSD RAID 0 Write-back Cache ON Composite about 3 Weeks


SSD RAID 0 Write-back Cache ON Graphs 3 Weeks

I had to collect the "three week" data 1 day early due to travel. In a stunning reversal, the sequential read performance is nearly back to the original value. If it is due to garbage collection, I wonder how it happened? I didn't log off Windows 7 and I don't remember leaving my computer idle for very long. Is it possible it is based on power-on hours, startups, or host writes? In any case I will keep monitoring and see what happens.

My next update will be on the 23rd or 24th.

[malventano]

My next update will be on the 23rd or 24th.

Not trying to bust your bubble or efforts, but you're running a benchmark which only samples a small portion of the array to obtain its results. Further, since that benchmark runs on an in-place partition, it must use free space to do its testing, which means it is less likely to hit a fragmented area (i.e. where random writes had taken place).

P.S. Tony TRIM is not only a waste of time and flash erase cycles (premature wear), it forces the SSD to allocate *all* LBA's in one shot. If you only ever used 50% of the available space, the SSD would last *much* longer as it would have more available free flash to work with. Most modern SSD's will treat unused LBA's the same as if the drive was overprovisioned in the first place. Let the drive straighten itself out when you do the big writes to it via normal use, and if you're in a situation where TRIM might not make it to the drive, the less areas of it that you write to, the better.

Lastly, I *think* the most recent Intel RST drivers are able to TRIM through RAID-0. I haven't had a chance to confirm this.

[Gollan]

SSD RAID 0 Write-back Cache ON Graphs 5 Weeks

The SSD RAID 0 array performance seems to be fluctuating within a fairly narrow range of sequential read speeds. At this point I can say that the lack of TRIM support has had no effect on the performance of the array.

To make it clear, the point of this exercise is to find out what happens to SSD performance over time when they are put in a RAID 0 array and thus do not have TRIM support. There are many Internet postings bemoaning the lack of TRIM in RAID and dire warnings about massive loss of performance because of it. I'm also enjoying trying to figure out what the dependent variables are with performance, but it is probably more a matter of file system fragmentation - in other words, random within a range.

[Gollan]

An update at eight weeks. Still no performance decrease.

As performance values have fluctuated by up to 100 MB/s, I want to see if CrystalDiskMark gives consistent values when it is run several times in a short time with a restart in between.