RAID experiment - For the Experts

Pachanga schrieb am 05.02.2008 um 23:07 Uhr

It is a long one, but stay with me.

After a lot of number crunching I concluded that I did not need the performance of RAID 0. BUT, after a few test runs on my new system I am not so sure.
HP XW8600, 1 x Xeon 3.0 Quad (with open socket), 2 GB RAM, 7200.11 SATA drives : 250 O/S, 750 Capture/Projects, 750 Renders, 1 TB backup.

Since I only work with compressed video (DV or m2t), tape to PC transfers are no brainers (my HP 41CV calc can do it). For renders I need to read and write as fast as 4 cores (8 later) can chew the data.

The more complex the render, the more work the processors have to do, the lesser the demand on the drives (the CPUs choke).

I ran John Cline's rendertest at 1:51 sec. with all 4 cores at 98%. Both the read and write disks barely registered above 4 GB/s. So I made the right decision in not striping. Did I?

I made a validation test for the drives using large file transfers and all 7200.11 drives showed that they can sustain 100 MB/s and spiked to 108 MB/s (Their spec is 105 MB/s)

BUT ... When I ran simpler projects in DV, rendering to MainConcept MPEG2 using standard DVD template something interesting showed up.

The 4 cores only run at 70%, meaning they can do more, so I suspected the drives were not reading or writing fast enough. Oh no, I needed the RAID 0 after all. But did I?

Further testing showed that the "read" drive only would work at 11 MB/s while the "write" drive only worked at 4 MB/s. That is a lot less than the drive's capacity of 100 MB/s I had just tested.

I setup a series of tests. 1) with separate drives for read and write. 2) "read" and "write" in a single striped volume. 3) "read" on the striped disk. 4) "write" on the striped disk. You still with me?

INTERESTING RESULTS: With "read" and "write" from a single RAID 0 was slower than separate non-striped disks (R =7 MB/s, W=4 MB/s), all other tests had identical results wheather or not a striped drive was used (R=11 MB/s, W=4 MB/s). By-the-way, Vegas only uses 300 MB of memory on all tests.

THE MYSTERY: If the drives can work 10x faster than being used, and the 4 cores are only working at 75%, WHAT IS THE HOLD UP?
Where is the bottleneck.

Zurück zum Post

Kommentare

Pachanga schrieb am 08.02.2008 um 19:16 Uhr

Rob,

What you say matches perfectly with my recent tests. I rendered the test project using different compressions. from DV (*avi) to uncompressed, and to DV (no recompress needed), and the CPU's usage significantly dropped while the drives nearly quadrupled in tranfer rate (still well below capacity).

I guess I can safely say to those starting in video that if working with compressed video (DV or m2t):

1). There is no real need for striping drives and thus doubling the risk of failure.
2). Four (4) cores is as efficient as it gets today, at least with Vegas.

I wish I would have had the benefit of your comments a few months back. I hope others get to see this.

megabit schrieb am 11.02.2008 um 13:38 Uhr

Pachanga, no offense please, but all your speculation about no need for RAID 0 (or superfast HDD's in general) is BS.

Take this real-life scenario: Vegas opened on a XP (or Vista) with 4GB RAM; a couple of documents opened (Word, Acrobat, Excel - you name it); plus some IE pages and, of course, your e-mail client.

Let's now assume you HDDs have been defragmented; now you come to your office with a couple of clips on say two 8 GB SxS cards. You open the Clipbrowser and start downloading / exporting them. Once the first mxf is ready for you, you cannot wait any longer and open WMP to watch it ,,,

OK, all the clips (say some 10GB) are now ready (and having fragmented your nice HDD). You want to load them all to Vegas and start editing....

Now measure how long your HDD's trashing lasts in proportion to anything else that can be done on your PC, before it ever becomes responsive again.

The bottom line being that - If I had enough cash, I'd have at least 3 sets of RAID 0's in my PC; if I had even more - 4 sets of RAID 10 !

Pachanga schrieb am 11.02.2008 um 14:35 Uhr

megabit,

"Pachanga, no offense please, but all your speculation about no need for RAID 0 (or superfast HDD's in general) is BS."
No offense taken.

I think you did not follow the discussion from the start. I am talking about beginner and hobbie editors (like me), which I read a lot of questions from, asking how to get started. Most have a prosumer camera for home or corporate videos and hardly use uncompressed video, just like we discussed earlier, DV or m2t.

I also happen to have fast raids (and less cash), 6 x 15K rpm SAS Cheetahs (it doesn't get any better than that). I do not use them most of the time because what I do does not justify having a pair of F-18s revving up their engines next to me, while sending cash to Hugo Chavez for oil. Those are from my pre-Vegas era of hardware NLE and uncompressed captures.

I have enjoyed the performance of my F-18s, but, simple internal SATA drives may do just as well for the many ocassional editors out there (like me) who take-on a weekend project twice a month. All internal, no need to build an addition to your home and have the power company install an extra tranformer outside for the multiple array enclosures.

MH_Stevens schrieb am 11.02.2008 um 17:02 Uhr

Are you running Vista - I don't see your os mentioned -because if so what does the Windows performance index show? Secondly for all your processing power 2GB RAM is not nearly enough IMO. Put in 4GB Ram and run Vista in 64bit mode to take full advantage of what you have.

Also how many logical drives do you have your RAID split into. Need to render on a drive separate from the os and for that drive to have its own page-file.

Pachanga schrieb am 12.02.2008 um 01:54 Uhr

MH Stevens,
I am running XP Pro. I am about to add 2GB for a total of 4GB of RAM. However, during all testing I did, task manager never showed RAM usage above 600MB (1.5GB free), with Vegas only using 300MB at most.

"how many logical drives do you have your RAID split into"
All are SATA internal drives,
One separate disk for OS and programs, logical drive C:
One separate disk for "Capture/transfer" of original material, E:
One separate disk for Rendering output, F:
One separate disk for project backup, G:

One of my tests tried two activities in one RAID volume (see above) and as expected, that was the slowest result, despite of being striped.

"... and run Vista in 64bit mode to take full advantage ..."
If Vegas is not 64-bit, how can Vista help?

MH_Stevens schrieb am 12.02.2008 um 02:49 Uhr

64bit Vista will let Vegas use RAM that is reserved for some of your hardware under XP and it will allow programs almost full access to the 4MB. With XP you may not get much out of the extra 2GB. There are however many here who know a lot more about this than me and I hope they will respond too.

farss schrieb am 12.02.2008 um 12:09 Uhr

A few things worth considering.
I've seen a sub $10K desktop system playout 2K dpx files (thats 10bit 4:4:4) with CC applied. The main thing is running the disks in RAID 10. That's a friggin lot of data being moved very fast.
Once you work with compressed files and add FXs remember the frame has to be decompressed, the FX calculated and the the frame compressed again.

Most video projects are more than 1 track, we've got one soul here running 122 tracks for his movie. Now most of us don't end up with that many tracks but a couple of video tracks and a few audio tracks are pretty usual for me. That means reading from multiple files and more head movement, that's what slows disk systems down. Systems such as SAS support Native Command Queing, that can really reduce the amount of disk seeking and hence sustained throughput. i haven't heard it mentioned in years but SCSI disk systems I used to work with had a thing called Elevated Seek, that seemed to speed up real world performance.

Mostly render farms are used for CGI, not so much data needs to be read but a huge amount of calcs are performed and large amounts of data written however unlike compositing the tasks can be easily split across CPUs.

For certain if you're editing as a hobby massive RAID systems are overkill. If you're doing color grading for the silver screen they're the norm. Large RAID systems are very expensive, I've tended to just look at how cheaply you can throw 4TBs of RAID together. I suspect there's quite a difference between the systems that cost $1K/TB and the ones that cost >$10K/TB

In general nothing beats efficiently written code. General purpose NLEs seem to choke on tasks that purpose written apps whiz through. Of course the vendors sell very few of those specialised tools so they're priced accordingly.

Bob.

rmack350 schrieb am 12.02.2008 um 15:00 Uhr

In fact, Darren says he's got up to 220 tracks in a project, but it appears that when you do that HDD throughput ceases to be an issue...

Rob Mack

Pachanga schrieb am 12.02.2008 um 17:40 Uhr

Farss,

That is the way I see it. After a lot of shopping I found out that the throughput of my SAS 15k rpm cheetahs are not much better than my SATA 7200.11. However, when it comes down to seek/write times and latency, the SAS drives are still much faster.

Now, this is something I still do not understand: If we work with large video files (4GB +), would the drive only have to seek once and transfer to RAM, or does it have to read that large file in multiple smaller data chunks?

If it only seeks once, then the faster seek and head movement of the SAS will only matter if we have a "zillion" files, like on a server database. Does anyone know how this actually works?

Kennymusicman schrieb am 12.02.2008 um 18:07 Uhr

The parts of the files are split up into chunks - and stored initially as sequential sectors on the HDD. OVer time, these sectors can become slightly scattered through moving, copying, editing and so forth - hence why a disc becomes fragmented, and the call for defragmentation.

I doubt very much if a large file is entirely commited to RAM - windows will try and guess an approx proportion to store initially, and add more to the RAM upon first call of the latter parts of the video file.

You have to offset the benefit of speed of RAM will the vulnerability - a power cut will lose everything stored in RAM - so a fair amount is double tracked onto a HDD file as time goes on (ie, when it has some spare time it can copy some RAM info onto HDD)

Also, if you're talking seek/write times and latency, you need to compare burst and sustained times too - they can impact depending on what you need.

As it stands, Vegas can only address 2GB, so that's all you have to play with. Until the 64bit version, or the Vegas is modified to make it LAA (and able to see 3GB) then you really do only have vthe 2gb limit in memory.

farss schrieb am 12.02.2008 um 19:32 Uhr

Almost certainly Vegas will not cache the data coming off the disk, at least not XGB of an AVI file. Don't forget it's got to cache all the thumbnails and waveforms. On a big project that alone it seems can use up all the RAM.

Bob.