View Full Version : Dropping frames/RAID performance drops

06-13-2007, 12:02 PM

My system: Apple G-5 dual 2.7, 4.5G ram, PCI-x slots, Kona 2 video capture card, OSX 10.4.9, QT 7.6, Kona driver 4.0. Using Final Cut Studio 2 (FCP6), editing uncompressed 1080i 10 bit, about 165MB/s per stream, all tests below are one stream.

RAID: 2 new Burly 5 bay port multiplier enclosures, 10 SeaGate SATA II 500 GB drives, CalDigit Fasta-x 4 port controller card in slot 4, the 133MHz stand-alone slot (its own buss). Striped in RAID 0 using Apple's disk utility; I wrote zeros to the drives to index any bad sectors. 256K write blocks.

the problem: about every 3rd to 7th time I play a clip, I get dropped frames reported at random points in the file; never the same place. Testing with AJA's system test utility, average performance is right around 375MB/s read and write; however, about every 3rd to 7th test I get large performance spikes down to the 75-125MB/s range: this seems to correlate to the frequency of occurances of dropped frames in FCP playback.

Anyone out there have any suggestions?


SaltAire Cinema Productions

06-13-2007, 01:37 PM
How full is the RAID?

I wonder if 'short stroking' the drives to 65% capacity or about 300GB each, would help?

Or if reducing the number of drives to 4 for each channel could help?

Or doing both?

But this is Ricks area of expertise, and should be back around later.

When I've run Intech's ZoneBench utility I've seen where a drive seemed to have a 'bad spot' where it would dip down over a small area (maybe there were bad sectors when it was created). Zero all may be a nice way to test a drive, and may map out some weak sectors, while a 7-way write erase will do a thorough job.

Speedtools offers QuickBench 4.01, ZoneBench (you can test 50 zones, writing a 511MB test file 30x), media scan (can find and map out bad blocks non-destructively without the need to initialize erase), and an integrity test. Obviously you don't want to test all 10 drives but to narrow down to see if there is one drive 'acting up' or causing a problem.

Are all the drives the same revision and firmware? bought same time and place?

Maxtor was optimizing their SCSI drives for video so that even if there was a bad block, the spare was on the same cylinder to reduce seek delays. Not sure if Seagate is doing something like that or not.

06-13-2007, 03:24 PM
Well, I heard about the phone call on this and we all discussed it here for a while. And Brian called CalDigit engineers to see what they had to add. The main guy there is out of town on a business trip to the east coast, so we won't have a quick answer from them.

I haven't heard anyone else with a similar issue - at least not exactly the same. I did have one phone call recently from a long time customer where he notices a spinning beach ball when trying to access drives, any drive... randomly. He clicks on a file or directory and gets a spin for a few seconds before it opens. Annoying, but his FCP use wasn't directly effected with dropped frames or anything. Happens on internal drives and external PM attached Burly drives. I have him monitoring with Activity Monitor to see if he can find a causality that leads to a fix. He is also running 'top' in Terminal to observe processes for the same purpose.

5 Drive PM setups are the most common. We sell more of them than 4 drive. The extra drive gives a good amount of headroom. More 5 bay PM enclosures are successfully used than any other.

Seagate drives are the most commonly used and most reliable of all as well. And we know the source of those drives, they are standard retail drives from MacGurus.

Gotta be something systemic. Whether caused by drivers or chipsets, I don't know. Could be as simple as a bad method of caching or a log process that stops other processes. Let me check around and see what we can change to make a difference. If we can make it worse or better, we can figure out what it is. And then find a fix.

You might try manually removing the 2 files that the CalDigit installer put in your system. First one is:




Delete the entire SICoreServices folder. Then download and run a new copy of the 2.0.3 driver package (http://www.CalDigit.com/Support/CalDigit%20FASTA-4%20v2.0.3.pkg.zip) and replace those files. See if that fixes things.

More ideas as we come up with them.


06-13-2007, 05:21 PM
To TZ: the drives are empty, brand new; all the firmware on each drive is the same. I don't have Media Scan; the version of Speed Tools I purchased was the Test Suite, not the full utilities package. I'll purchase that and give it a try if nothing else works. I appreciate the ideas.

And thanks Rick:

I'll try those things this evening as well as resetting the NVRAM and PRAM, as per Brian in your office. I'll report back.

I appreciate all your effort.


06-13-2007, 06:21 PM
If all of the other suggestions are not enough, I'll add one. You are using Apple RAID with 256KB stripes. That is what stuck out for me in your original post. I have long since forgotten the details of what my problem with 256KB stripes was, but it did not work reliably for me and I went to 128KB stripes. I had no further problems with that. k

06-17-2007, 02:57 PM
Hi All,

Well, two things worked for me. I reset the PRAM and the NVRAM, per Brian at MacGurus, and I went to the 128 block size, per Kaye. Although still not perfect, performance is much more consistent, with only the occasional drop, maybe every 12-13 tests or so. Also, the video seems to play back consistently.

An additional note: I went back to the 256K block, and the problem returned. So I went back again to the 128K block, and the performance improved again.

I really don't think this is a Burly Box issue; since the steps I've done that created significant improvement were essentially dealing with the computer system, I'm quite sure the problem lies somewhere in the way the data is handled before it gets to the drives.

Thanks for all your help,


06-17-2007, 03:33 PM
Have you tried 64KB Block size either?

Maybe the Kona is pushing the data in even smaller sizes thru the PCIX bus and if 128KB stripsize is giving you better results maybe 64KB will do better for your system? It is just a suggestion but, worse a try I think.



06-24-2007, 12:52 PM

I'll give that a try sometime this week; have to back up all the project video I've captured in the last couple days first;

Thanks for the idea.

SaltAire Cinema Productions

06-24-2007, 04:25 PM

To follow along with what Nicolas said, on my G5 thanks to Boots (the Photoshop expert) 32KB stripes with my RAID worked best for Photoshop CS2 and CS3 with his Pshop Test and large file sizes. My RAID did double duty working with the file and Virtual Memory when real memory ran out.

I should also point out that I prefer SoftRAID 3.6 set for Workstation and the 32KB stripes. k

06-25-2007, 02:50 PM
Info about Audio popping using 10.4.10 - so yhis might not help your exact situation.