Depends on the chipset and some constraints.  If you have the sandforce chipset then wear leveling is a function of, all things the p/n and an algorithm based on the remaining months of the warranty.  Then you have to look at compression, which is real-time calculations that vary depending on the type of data.  Go with a micron or intel controller, and then there is no compression built in, so the rules change.

If you want more, be specific on the SSD, controller, RAID config, host O/S, etc..   The generic answer is, it depends.

The current issue is that no RAID controller supports TRIM.    That will, I'm sure, change in the hopefully-not-too-distant future.

Meanwhile, the stripe size doesn't have a direct impact, but it can impact just how often you need to run wear leveling utilities.     As long as you set up a scheduled run for the appropriate utility, it's unlikely that the stripe size will matter.

Gary - actually LSIs software is in general availability.  It will set you back a bit and only works on a subset of their latest controllers.  

Stripe size from wear level position isn't significant enough to worry about unless you are writing full time at interface speeds maybe 8 hours a day, and the internal chip does play a huge factor.  I can't get too deep on internals as I have an NDA with one of the manufacturers, but if you really need to know, and are an appliance manufacturer or white box manufacturer then ... :)

Also much more to consider - the file system, of course.  The way it works in NTFS is the "TRIM" is done in Win7 device driver.   It is in some LINUX kernels, but is pretty raw, and there are issues with RAID.  

The large reserved space is vendor/product specific, not 50% by any means.  As for massive RAID controller processing .. that isn't true.  Processing is almost zero overhead.  It is the I/O cycles that gets you.

I wrote code to do TRIM behind certain RAID controllers and SSDs late last year.  But good news is that my company's exclusivity clause expires "soon".  Don't know how it will shake out.  Doing it the right way requires modifying device drivers.  Doing it the "easy" way requires running code that slices out a reserved area behind each disk in the RAID, telling the SSD that this is "reserved", then doing some stuff I'm not going to reveal.

In any event .. don't worry about stripe size, not a significant factor.  SSD chip manufacturer, host O/S, RAID config, file system, type of data are more important, and all to varying degrees as the SSD chips have proprietary and unpublished algorithms that can significantly affect performance  (i.e,  several hundred percent easily)

Obviously, if you define your stripe size to equal the SSD NAND page size, you will optimize the SSD life.
Most early SSD had 4KB pages, now they should be at 8KB or even more to allow such sequential througput we saw.

In fact, you should NOT care of that. You should care on:
-aligning your partition to 1MB (or another power of 2 like 64KB)
-define your stripe size to equal your IO size on system requiring IOPS optimization (no parity raid 5/6/50/60)
-define your stripe size to 256KB or 512KB in any other situation
-forget about this useless TRIM feature (useless because most FS update sectors...marking them for replacement without any fancy "TRIM")

Thanks

"... forget about this useless TRIM feature ..."  ==>  I would hardly call TRIM "useless".    SSD performance can degrade significantly without either TRIM (essentially transparent to the user) or a utility that is run on a scheduled basis to do effectively the same thing (such as Intel's utility in the SSD toolbox).    

dlethe =>  Glad to know that LSI now supports TRIM in their RAID controllers -- I knew that was coming, but wasn't aware it was already available.

I simply don't think stripe size is a signfiicant factor when using an SSD.   None of the factors that optimizing stripe size help mitigate (seek time, rotational latency, etc.) are relevant with SSDs.

It depends on the make/model of the SSD & the I/O size, as well as the chipset.  I've got NonDisclosures with some vendors. so can't name names but some models effectively have no need for any TRIM, while other models of SSDs will see write performance range anywhere from 50MB/sec - 280 MB/sec depending on this stuff.  Some do horrible if the I/O is not a multiple of 128KB, and others that have built-in firmware compression will see at least a 75% hit on data that is heavily random vs data that can be compressed.

@garycase: forget about this useless TRIM feature (useless because most FS update sectors...marking them for replacement without any fancy "TRIM")

The TRIM feature is usefull only when you delete sectors as it notifies the SSD that they can be reclaimed which enable a better garbage collection...and TRIM disable any UNDELETE feature.
TRIM is useless for most current enterprise usages:
-Database
-Virtual disk files

ALL current SSD controllers do NOT care about being notified of some deleted sectors to be able to efficiently run their garbage collector. I agree that some rare desktop usages may slighly suffer from a missing TRIM.