Is the RAID hardware or software based? If it's software based then the CPU has to dedicate cycles to it every time you read or write. Generally since video files are large, then you don't want small stripe sizes.

Why are you even bothering with RAID?

It's hardware based as I said, a SIIG eSATA express-card.

Bob: Another thing, GUI or master Boot? The software is a GUI driver and I think I have set RAID as master boot. Could this be an issue?

Ah perhaps not. Yes it uses hardware however only the high end RAID controllers do not make extensive use of the CPU.
I'd suggest try running something like Intel's IOMeter. What you need to aim for is the best Sustained Transfer Rate for video and at the same time the lowest possible CPU uitilization.
That 3GB/sec figure is the maxiumum data rate of the SATA II buss. If you managed to get 50% utilisation of the buss you're doing very, very well.
Where these kinds of controllers and RAID setups will seem faster is in say copying very large files. Streaming and processing video is another matter entirely.

Bob.

So, are you saying Bob, that for editing, ie storing the project and the media RAID0 is of no benefit and that I might as well go back to a single drive? Are you saying the RAID0 users only use RAID for storage of large projects and not as a working media?

Not exactly.
It depends on the type of RAID 0 controller. For servers serving out data on corporate networks the CPU overhead isn't such a big factor. However with video your system needs both fast data rates from the disk system and as many CPU cycles as possible. So having the drivers for the RAID controller using up CPU cycles isn't a good thing i.e. you gain on the one hand and loose on the other. In your case you seem to be loosing more than you're gaining.
Also keep in mind that RAID 0 has no fault tolerance, compared to a single disk it's at best half as reliable.
RAID certainly has its place in the video and film world. I have a PC with RAID 0 off a Highpoint controller that's pretty good for 10bit YUV. The controller is plugged into a fast PCI slot, remember everything slows down to the slowest buss. Even so that controller is using up CPU cycles. In my case with Xeon CPUs not a big factor but a more capable / expensive controller would have been my choice if I knew then what I know now.

In your case, you're probably better off just sticking to a single disk on a eSATA connection. You could consider an external drive with the RAID being done in a controller in the external box however you might well find that your laptops internal buss is limiting how fast it can all go anyway. If you're working with HDV/MXF the data rates are not great, it's the CPU that has to work hard any way. Given the risk with RAID 0 I'd tend to not go there for your kind of footage. Even on my big box coming off the RAID drives or just the old ATA drives I don't see any significant improvement in performance with mpeg-2 source material.

Bob.

Thanks Bob. I'll just use the SIIG to give me two eSATA drives, a work drive and a backup, and forget RAID.

Mike

I don't know if I can simplify this but I'll try. Regarding the need for Raid0, I find that a single hard drive has enough throughput for a codec like Sony YUV in SD but to play back an uncompressed SD AVI file I need a 2 disc striped array.

For HD, the throughput needs are even higher.

The advantage of using Sony YUV, HuffyUV, or uncompressed media is that these really don't take much work for the CPU to decode. The tradeoff is that the files are so big that your storage system needs a lot of throughput. Your computer's CPU and memory subsystem have enough throughput for the media, but the hard disks need some help, and that's where RAID-0 or 5 comes in.

There is, however, a problem with RAID. RAID-0 requires a little bit of processing power, RAID-5 requires quite a lot. An inexpensive RAID controller will use the computer's CPU for this power and this can sap away a bit of performance that might be used by Vegas.

So, what do you need? If you plan to work in lightly compressed, CPU-friendly formats then RAID-0 or 5 should be the right choice. If you plan to work in heavily compressed, CPU-heavy formats like AVC or MPEG then RAID-0 probably won't help. In any case, when you chose a RAID controller you need to hunt down one that does all of it's own processing.

Ideally, if you need some disk throughput improvement but not TONS of it, an external enclosure with it's own RAID controller that can be fed with just one eSATA cable should negate any possibility that the CPU has to do any work to support RAID. SATA300 should have enough throughput to support a modest striped array even on just one SATA channel.

I don't really think that any of this explains why your striped array is slow. Even though it may suck down CPU cycles to use it, the array should be faster than a single disk. As a simple test, if you were to take some SD footage and render it out as uncompressed, it should play at full framerate off that array. If it doesn't or is worse than a single disk then you've got a problem somewhere in the hardware chain. Maybe it's the drives, maybe it's the controller.

The ExpressCard slot supports both PCIe and USB2.0. The USB2.0 support is there so that manufacturers with USB2.0 gadgets could port them to the ExpressCard format ASAP, speeding the overall adoption of ExpressCard. I have no idea if this is a factor for you. It'd be weird if it was the case but not impossible if some part of your data chain is converting between USB2.0 and eSATA or even eSATA to PATA at the disk end of the line. I'm not sure how you'd determine any of this but I suspect you're seeing a hardware problem rather than a CPU overhead problem.

Rob Mack

If it helps to make your advice Rob, more specifc, I edit only full HD in Cineform avi format.

If you think I should try the RAID again what chunk size shouls I use. I'm asked to choose from 8 to 128.

Mike

Beats me what the best cluster size would be...

Given that you'll alawys have sfk files to read, I'd think that a cluster/block size that's half the size of your smallest SFK files would be enough to split those files across two disks and so speed up their reading and writing. You could go bigger if you're just concerned with media files, but you still probably want to set it at less than half the size of the smallest media files...probably much less than that.

Seems to me that my integrated nvidia RAID setup defaults to 64KB. This is one of the slower RAID controllers but it's definitely faster than a single SATA disk on my computer. I don't care what cluste/block size setting you have, if your array is slower than the same disks on USB2.0 then there's something wrong.

<edit>I was just looking around at random chitchat on the subject and found one person making a point that you rarely read an entire media file all at once so you needn't set your block sizes too big. Imagine if Vegas had to read 128 KB of data every time you park the playhead somewhere? I think I'd probably either stick with your controller's default or maybe chose something half the size of an sfk file.</edit>

Rob

In the interests of some dodgy science I just ran HD Tach 3.0 on three disks connected to my 2.4GHz Core Duo:

WD 1TB My Book via eSATA:

Burst 100.9 MB/s
Av. 40.0 MB/s
CPU 7%

Samsung HD120 IJ via SATA

Burst 124.8 MB/s
Av. 49.5 MB/s
CPU 5%

Unknown drive via firewire:

Burst 26.9 MB/s
Av. 24.7 MB/s
CPU 2%

All of those should be able to deliver data to the CPU fast enough to playback a single stream of DV, HDV and I think CF DIs.

What surpises me is the slow performace of the WD MyBook via eSATA. 1TB drives should be faster than 120GB drives!

I'll leave it upto Mike to compare figures on a single MyBook and two in RAID 0. Get HD Tach from here:

http://www.simplisoftware.com/Public/index.php?request=HdTach

Bob.

For comparison:

Sil3512 RAID 0 (an onboard RAID controller in RAID 0 using two Seagate drives)
--Burst 121.7
--Average 110 MB/s
--CPU utilization 1% (+/- 2.0%)

Single Seagate ST3160023a on an nvidia SATA controller (250 chipset)
--Burst 92.1
--Average 46.4
--CPU utilization 3% (+/- 2.0%)

Here are my results using HD Tune (Bobs link not work for Vista) and 64 bit chunk size. MB/s and ms, %

Dirve,Min Tns;Max Trns;Ave Trns: Access time;Burst Rate;CPU Usage.

c:;32;65;51;14.8;83;5.5
WDMB1;35;55;48;15.4;38;1.6
WDMB2;29;56;44;15.3;38;1.4
RAID0;39;64;60;12.8;38;2.2

When I ran Vegas before I had a chink size of 8, so maybe 64 is much better?

Look how slow the MYBooks are. Maybe I got the wrong drives?

Mike

The figures for the WDMB are very slow compared to the same drives on my system, I can manage a burst rate of 100MB/sec compared to your 38MB/sec.
Either it's Vista or your eSATA controller or your Express Slot holding things back. Which laptop are you using.

Bob.

I'm using the Sager that someone here recommended(?) and I love it. The specs are:

Sager Midern Notebook
Intel Core 2 Duo T9300 @ 2.5GHz
RAM 4GB
Vista 64bit
Windows Expeience factor 5 overall

I have all updates and latest drivers. WD HDD Manager does not show any errors. I'm NTSC formated.

I'm kind of out of ideas. My figures were from a Core Duo @ 2.4GHz in a Shuttle XPC, that's a slower system than yours by quite a margin. The eSATA connection is directly from a spare SATA port on the mobo.
Even your C: drive seems slow, I assume it's a 7200rpm drive?
How are your SxS transfer speeds, as that's using the same port as the eSATA card it might reveal something.
The only other thing to consider is Vista 64bit. I know less than nothing about Vista but it does seem to have had some speed issues. Are the drivers for your eSATA card Vista 64 certified or whatever they're supposed to be?

Have you tried the cards manufacturer?
I must admit I did a Google and didn't find any real reviews of it.

Bob.