I have been working on building an 800gb Raid5 array to hold all of my DVD's. I just installed a RocketRaid 454 controller and 6 160gb ATA133 drives. The system seems to be very slow. It also consumes 100% of the CPU usage while doing a transfer. As an experiment I transfered a 1 gb file from the slave drive to the master drive on the primary ide channel of the motherboard and the CPU usage was between 20 and 35 percent. When I transfer the same file from the slave drive and the primary channel to the Raid5 Array CPU usage shoots up to 100% and the process takes 3 times as long.
Any ideas on what is going on? The same thing happen if I connect the drive I'm transfering from to the raid controller as a drive the is not a part of the array. No increase in transfer speed and still uses 100% CPU. Is this because I bought a cheap controller card? Could it be due to the fact it must transfer through the PCI port? Do you think that purchasing a better controller will fix this? I really don't mind the transfer rate but choking the CPU is not acceptable. I can't do anything else on the computer while files are being transfered.
Heres a breakdown of my system

Windows 2000 Professional SP3
Asus A7M266 MoBo
512 mg PC2100 mem
Athlon 1800+ CPU
GeForce MX400 GC
SB something Audio card
Highpoint 454 Raid5 controller
3com 10/100 lan card

I have installed all of the latest drivers.

I figured if anyone would have an idea of whats up it would be you guys.

Thanks!

First question - are you using software RAID, through Windows 2000, or are your devices programmed through the array controller? Also, are the RAID5 devices still building or rebuilding for any reason? Are there any activity indicators when you are not transferring files?

Thanks for the reply Paul. The array is built through the Highpoint RocketRaid 454 controller using the tools built into the controller. Checking Task Manager now shows a CPU usage of between 0 and 1 percent. I just checked the Management Console for the controller and under Array Management the Raid5 Array is show as complete and available. This raid controller has no memory on it that I can see. I think it must just use system resources for most of its functions.??

Dunno if these are in any way related to your dilemma, but when I had similar disk drive symptoms (100 percent CPU usage and slow performance), it was because I had used 40-conductor IDE cables instead of the new 80-conductor cables when installing the disk drives.

However you say the drives are 133mhz, does that mean you're using the newfangled "serial" cables to connect the drives instead of the IDE cables?

Another thing to check is to make sure the "DMA" check box is enabled on the drives in the Windows Device Manager.

Can't be Serial (SATA) as the card he's using doesn't support it. In fact, the only ones I know of that do are the new Escalades.

I'll bet it is the fact that system resources are being used. I don't believe that card is entirely hardware based. A hybrid, maybe.

ATA133 is a 80 pin cable. It's SATA that does 150mbps and has the tiny cable.

Try removing the SB card and see if that makes any difference. I have a PCMCIA controller card and a 2GB PCMCIA Toshiba disk drive (not flash) and transfers to it are very slow. I've never resolved the problem, but remember reading about a poorly written SB driver that polls the processor (via the PCI bus) and it was these hardware interrupts that caused poor performance.

Although my confidence is low that this is your problem, it's any easy thing to try removing the sound card. Good luck.

-Zeke

Thanks Tony, the 133mhz was a mistake the drives are ATA133's. I am using 133 rated round cables on the drives. The only two choices I have in Device Manager for the array are "Disable tagged queuing" and "Disable synchronous transfers" both boxes are unchecked and both boxes are under the SCSI Properties heading.

Yeah, I think your right. I think I'll bite the bullet and pick up a Promise Supertrak 6000 to take its place.

I don't think thats it either but what the heck? Its worth a shot.

Thanks

Another little tidbit here. I just started to rip one of my movies to the array and noticed the the read rate flucuates from x1 to x4 and the estimated time flucuates from 20 mins to 2 hrs. these changes are cyclic and repetitious. When I changed the destination to the D drive (not on the raid controller) the read rate was back to normal, X2, and the time was steady. Do you think if I had a 3 ghz machine I wouldn't have this problem?

What is the sripe size on your RAID? If it is really low that could affect performance. Other than that it really sounds like your drives aren't being recognized as connected via ATA133. If it has fallen back to a PIO mode you could expect crappy performance and higher CPU usage. You might try ditching those snazzy round cables for some basic 80 conductors.

-Mike

Yeah, I've heard other people complain that they've had nothing but trouble with those round cables.

Checking the array manager shows that all the drives are list as ATA133 for the transfer mode. I think I made a bad choice in card selection. Too many system resources are being used to support the controller.

So you guys think that the round cables might be causing my troubles? I think I might have enough flat cables to give it a try. I'll let you know what I find out.

Too many system resources are being used to support the controller.

That's (IIRC) because the Highpoint cards are software RAID solutions with hardware acceleration. If you're worried about system resource usage, get a 3ware escalade card, which (I believe) are proper hardware RAID. They're not cheap, though.

I'm not 100% sure about this, though -- it's just what I found when looking for a card for my Linux box.

might have enough flat cables to give it a try

My Highpoint RocketRaid 404 came with a complete set of 80-way cables -- one for each channel. It was a retail boxed one, though.

The Pacific Digital DiscStac cards are also very good at this type of thing. Up to four ATA133 drives per 32-bit card. Software raid, but the hardware has a HUGE assist even for regular ATA R/W, so the raid isn't much of a challenge for any modern CPU.

Outperforms 10K RPM SCSI with the right drives..

Cheers

Yes the 454 did come with cables. They are too short though to reach the drives in the SuperAlien case that I am using. I'll look into the Escalade as a possibe solution. Thanks!

Too short? Are the cables you're using the right length? There is a limit on how long the cable should be. Mark will probably know more about it as he's the IDE guy.

The limit is normally 16".

I do know that the Pacific Digital cards include MUCH longer length cables, but their cabling is "special" and so they can do that very reliably. Perhaps others do something similar (?).

Cheers

I noticed your using an MPX motherboard. You need to read this and this

I have 4 Tyan MPX boards and everyone one of them has this problem, unless you only use the 64 bit slots.

TMan, you might be right. The cables I am using are 24". The reason for this is that they are dual drive type and the slave connector is 16" from the system connector. Anything shorter won't reach. I have purchased a new raid card. When it arrives I will use six seperate cables and they will all be 18" or less.

Attack, Thanks for the links, that is pretty interesting. I don't think it is my problem however as I didn't have this problem, even writing to drives on this controller card until after I built the raid 5 array. I am convinced that this is due to the way the controller functions in a raid 5 configuration. The XOR computations that are done are handled by the main CPU and not a processor on the controller. The new card I'm getting does these computations through a 100mhz processor onboard, I think it should do the trick. Now if I can only figure out how to get a 13.5" card in a 10.5" space. Yep, the card is longer than the space I have to fit it. A slight oversight I made whilst in the heat of the battle on E-bay. It's nothing a high speed abrasive wheel some aluminum and a few rivets won't fix. I'm going to have to do a little surgery on the internal drive cage and lose one drive bay but that won't be too bad.

Do you think if I had a 3 ghz machine I wouldn't have this problem?

For things like this, I really think a Hyperthreading processor would work well. The theory behind them should result in better speed anyhow in situations like this, when paired with a proper HT aware OS (Windows XP or Server 2003 being the MS ones aware at the moment).