GA-EP45-UD3P RAID 5 Performance (Gigabyte support seems a bit off)

I am getting terrible RAID 5 write performance (avg 15 MB/s). I'm wondering if I might have a defective motherboard. I contacted Gigabyte and I think the person I spoke with is on crack. He says the ICH10R controller is software raid. See the message chain below. Does anyone else here use the ICH10R controller in RAID 5 mode and what kind of read/write performance do you get?




Message Chain:
----------------------------------------------------------------
Sent : 10/25/2009 14:03
Question : I'm getting absolutely terrible RAID 5 write performance. It's writing at roughly 15 MB/s. I know there are write performance penalties when using RAID 5, but not like this. Does this sound like a defective controller to you?

Gigabyte: Which OS you are using and have you and enable the write-back cache setting?

Sent : 10/30/2009 23:43
Question : OS: Windows 7 x64
Write-caching defaults to enabled.

Gigabyte: That is all needed to be done, which applications you are testing with under Windows 7 and are those utility optimized under Windows 7?

Sent : 10/31/2009 14:35
Question : Everest
I also did some standard file copies using explorer, xxcopy, robocopy, copy, xcopy to/from a ram drive (eliminating the potential bottlenecks from the other drives, drives sharing the same raid controller, etc) I've read some other reviews of the ICH10R controller and it looks like they are getting the same write performance (ouch). However, they are getting much better read performance with similar configurations. Apparently, you're not convinced that it is a hardware fault (and neither am I), but I wanted to get your opinion. I have both burnintest pro and everest and neither of the utilities are reporting any issues when I run their diagnostics. This is just very disappointing performance and I'm just going to have to suck it up or by a dedicated RAID controller. If you do feel that it's likely a hardware fault, let me know and I'll do what ever troubleshooting is necessary to get a replacement.

Gigabyte : since it's software raid it can only perform up to an certain spec. You can obtain an raid controller card to use hardware raid.

Sent : 11/3/2009 04:44
Question : You lost me or I lost you somewhere in this conversation. It's NOT software RAID. I am using the ICH10R integrated controller on the GA-EP45-UD3P motherboard in RAID 5. The Seagate 7200.11 drives average around 70 MB/s write speed when not used in RAID. In your opinion, should I be getting a faster write perfomance than 15 MB/s when using RAID 5? If your answer is yes, I need an RMA issued. Sorry for the confusion.

Gigabyte : The Intel ICH10R is software raid, the only way to monitor and rebuild the raid is within the OS with the utility running. Hardware raid can perform rebuilding within the bios not only in the OS. You can try running SiSoft Sandra as well and compared your results to others
Certain drives are faster than others so perform on different drives will may not be the same.

I'm pretty sure that software RAID is controlled through the operating system.

According to Intel's ICH10 datasheet, it has two controllers for the six ports.

I don't doubt that those controller(s) may use the CPU for calculations (potentially the reason for the terrible RAID 5 performance), but I doubt that this is considered software raid. ICH10R is the southbridge chipset and I don't know how to identify the RAID controller other than by what is quoted above as Device 31: Fucntion 2. If it was true software RAID, I wouldn't be able to configure it from the BIOS (which I can) and dual booting into other operating systems such as Linux or using winpe wouldn't recognize the array (which they do).

You have an underlying misconception here: firmware is software; it is simply 'burned' or 'flashed' into a piece of 'hardware memory', be it EPROM, EEPROM, NVRAM, FeRAM, MRAM - doesn't matter, it's still software in memory... There are two basic ways to run these programs - either the hardware is 'vectored' into the hard storage itself, to execute, using other volatile storage for working register blocks; or, the boot-strap procedure copies the ROM code into volatile memory, and executes there - once again - doesn't matter. Executing directly from ROM is usually fairly inefficient, as timings for VRAM are much faster - but, for a limited system, like a washing machine controller, or a coffee pot, you might get by with the micro-controller's own register memory for 'working' storage, and not need (the expense of) a memory subsystem at all... We just got a Roomba, and I've already downloaded its 'firmware', and am busy disassembling

Just because something is 'in the BIOS' gives it no special powers (or any particular 'boost' in execution speed, except for that it was likely done in assembler, and highly sub-optimized), it's just object code running on the processor. The BIOS makes a BIG difference to everything, though, as in the end, pretty much everything else is eventually vectored into the BIOS functions, one way or another... For example, about five or six months ago, Intel updated the ICH BIOS code, correcting some rarely triggered bugs, and obviously offering some better sub-optimization of the RAID functions, as it (in combination with new OS drivers [and only in combination with new OS drivers!]) increased throughput by about 5%; it took quite some time for manufacturers to 'propagate' these changes through their existing BIOS, and, for a while, there were a number of 'hacked' BIOS floating around for the faster platforms (X38 & 48, X58), incorporating the new RAID BIOS while waiting for the official releases...

However, no matter where the execution code comes from, it's still got to 'time slice' with the rest of the system's processor useage; the only way out is exactly the way that RealRAID cards do it - offload the work to another processor, with its own memory subsytem (and the medium priced RAID cards now accept two gig SODIMMs), or sometimes, as I mentioned, to a dual-core...

Ahhh... I'm going brain-dead:

that's the first thing I should have noticed - you likely have the dreaded "Seagate Stutter"; info here:
http://seagate.custkb.com/seagate/ [...] cId=207931
Download their ID tool and follow posted instructions carefully - updating firmware on some drives that don't need the firmware is known to render the drives inoperable...
I got a pair of 1.5s that had sequential serial numbers. 'broken off' the original Seagate foam OEM shipping foam thingie - one had the 'stutter', one didn't - who knows??