Hi wired,
I can only talk in light of my experience of last year, but still, maybe some tip can help you.
First of all, you should check if your raid array is at all capable of the write rate you're seeking. Do it with dumb writes of a fixed array, multiple of the sector size, and time the result (double checking them with a stopwatch as my previous experience showed...). Some snippet like the one I attached in the first message of this thread - since then I had improved versions of it, but I'd have to search. Mandatorily this has to be unbuffered writes, and the size of what is written at once may be critical - expect the optimum around some MB, perhaps related to disk and controller cache sizes. Only after that you should check for additional bottlenecks due to a) the fact that you're getting the data to be streamed from somewhere, and b) you may need to preprocess it before streaming - both operations may in practice severely interfere with the data transfer to the controller.
My previous attempts showed that there are hidden, or at least very obscure (to me) bottlenecks in every step involved. The RAID controller may simply not be up to the task. (My computer vendor, which I consider quite knowledgeable, and who went a long way to help out, forwarded me that it was nearly impossible to get, even from reputable hardware producers like Adaptec or LSI, real statements about performance of their controllers - nobody seemed to really care about RAID0, specs given were extrapolated and not truly measured, and so on). The Raid controller may sit on a bandwidth limited bus (in my case it was a PCI-e x4 behaving like x1, vs a true PCI-e x8, or sitting on the south rather than the nort bridge, and so on). Experiment a lot. Be prepared that performance may not upscale linearly with the number of disks connected. In my case I think we observed linear speed increase with up to 4 or five disks, then saturation (btw - I've also checked at that time different splitting and logical striping strategies of the available disk set at the OS level, but none could do what the controller itself was unable to do). It is usually easy to change the controller configuration on the fly, for that. Know also that the write speed is at best N times that of the worst disk, so if you have a single subperforming HD, it will spoil the whole performance. On 12 magnetic HD I guess that the chance of at least one subperforming is high; presumably not with SSD (which for me were both out of budget and not large enough).
When you have assessed that the array performs as requested, you can check further a) and b). As for a), I was sworn not (in my case - PCI-e is PTP conceived, DMA bandwidth is certainly way larger than needed), but still strongly suspect that some kind of motherboard arbitrage interfered with my framegrabber on one side pushing data to RAM and the RAID controller accessing RAM to downloload it on the other. My tests at this level checked for grabbing data continuosly discarded to RAM, AND at the same time trying to write dummy blocks to RAID. I was doing video, and the solution there was to get rid of the NI-1429 grabber in favour of a more recent Karbon one.
At the third step you should deal with the processing of your data. Keep in mind that any reshaping, truncating, padding the data to sector multiple may involve huge memcopies, which still steal RAM access time slots - and perhaps prevent the next data transfer to happen at the right time (?). Also here I'm speculating about what really went on with my motherboard, but to be on the safe side I strived not to do any - streaming write just takes the pointer of the beginning of the array and dumps the segment to the controller.
Hope this helps (and is not too trivial)
Good luck,
Enrico
