The increase in performance with a single M2 PCIe3 x4 SSD can be well in excess of using a RAID 0 pair of 840/850's; max sequential stats anyway, random loads can be variable, especially writes (applies to all disks of all types), but generally the M2 will just kick butt regardless.
Your idea of faster read speed of a RAID10 over a RAID0 is incorrect. RAID10 very rarely speeds up reads over a RAID0 of 1/2 the number of disks, despite having pairs with the same data, because the controllers just don't read data like that (not the usual ones anyway, although interestingly enough a Windows software RAID does and a couple of Unix flavours do too, a few hardware solutions can aswell, although they are usually rather expensive), and even if they did, the southbridge would likely be flooded (you've not mentioned a RAID controller so I figure you're going with the onboard).
RAIDs are not primarily designed for performance (despite the premise behind a RAID0), and the focus that is put on it when designing them. Redundancy is the aim, which is why it is in the name (although, as preached in many places, a RAID is not a substitute for a working backup strategy).
Using mixed drives your performance will be based off the level of the slowest performing drive in a RAID. Because the controller needs to wait for the slowest drive to finish it's action.
This happens on mech disks too, and is usually resolved by having a second+ copy of the install, which points to it being a problem caused by games file access strategy (and potentially locking/blocking), rather than the disk i/o itself. Faster read i/o will help hide it, but it is just trying to hold your bumper on with some gaffer tape. If it was determined which files were under contention, they could be virtualised in ISBoxer (if you happen to be using that), and that would provide multiple copies of the affected files rather than replicating the whole install.but I've heard about IO stutter with multiple instances of wow reading off a single SSD
As for your YouTube stutters. That would point to a different problem again. While YouTube does cache locally, there is also a memory buffer to account for read I/o being delayed, so if there are stutters, either the cache is empty (and thus your link to the server is not wide enough - which is not necessarily the same as your connection to your ISP), or the buffer is not being filled fast enough, or your CPU is busy doing something else, and does not have the resources to decode the stream. The buffer not being filled from the cache is the least likely cause.
Connect With Us