I just added an Adaptec 1430a card to my computer, moving 4 PCI-attached drives to PCI-E ports.  (http://lime-technology.com/forum/index.php?topic=2081.0)

 

Thought others might be interested of the affect on parity calculation speed.

 

PRIOR CONFIG (Using Asus P5B-VM DO)

6 drives - MB - ICH8DO (including parity)

4 drives - MB / PCI-E x1 - JMicron 383 (2 SATA, 2 IDE) (including cache)

5 drives - Supermicro AOC-SAT2-MV8 (PCI-X 8 Port Card in regular PCI slot)

 

NEW CONFIG

6 drives - MB - ICH8DO

4 drives - MB / PCI-E x1 - JMicron 383 (2 SATA, 2 IDE) (including cache)

4 drives - Adaptec 1430A on PCI-E x4 slot (including parity)

1 drive  - Supermicro AOC-SAT2-MV8 (PCI-X 8 Port Card on PCI slot)

 

I ran a parity check last night and it took 9 hrs 14 minutes.  As it started I took some readings (14 drives all running in parallel) - it was running at about 21,500 KB/sec

 

The parity check with the new controller took 5 hrs 58 minutes.  I took some readings as before - it is running at about 44,500KB/sec!

 

Total Savings:  3 1/4 hours - about a 1/3 less time.

 

(I have 1 300G drive, 4 500G, 5 750G, and 3 1T data drives.  At the 500G mark, the speeds should have been identical because only smaller drives were attached to the Supermicro card.)

 

I realize that this does not mean I'll get much better real world performance, but still pretty cool.  Now all I need is a fiber optic network to take advantage of it!

 

Updated original post.

I bet if you were to get fancy and shift the order of the drives you would get faster parity check performance.

 

I.E.

 

Disk 1 on ICH8D0

Disk 2 on JMIcron

Disk 3 on Adaptec

Disk 4 on Super Micro

then back around to

Disk 5 on ICH8D0

Disk 6 on JMIcron

Disk 7 on Adaptec

Disk 8 on Super Micro

 

Back in the days when I did raid across multiple promise P-ATA controllers, this made a big difference in performance.

I.E. No successive reads or writes were on the same controller.

 

The odd thing is that I do not believe it is always based on the bus/lane speed alone.

 

On my itx machine, all 4 sata drives are on one PCI promise TX4 controller.

Parity speed ranges from 45,000KB/s to 59,000KB/s

 

On my itx machine, all 4 sata drives are on one PCI promise TX4 controller.

Parity speed ranges from 45,000KB/s to 59,000KB/s

 

This does not sound right. The theoretical limit on the PCI bus is 133MB/s. The unRAID parity speed should mean that at least #drives x that amount of bandwidth is required, meaning not less than 160MB/s in your case. Am I getting something wrong?

Not sure what the deal is, I believe it may have something to do with the drives I am using.

I am using WD Green 1TB drives.  The 59,000KB/s is consistent across 3 different motherboards.

 

A Jetway ITX AMD geode with Promise TX4.

A MSI Core 2 Duo with PCI Promise TX4

Each of these had 2 500GB maxtors (7200), 2 1tb WD's (5400).

 

and now my ABIT AB9 PRO No PCI,  4 drives on ICH, Parity on JMB (this drive is a 7200 Segate 1TB).

 

After the parity check gets underway a while it climbs to 59,000KB/s never any higher.

 

The Nordco DS-520G is actually the slowest.

It has a 1GZ Celeron M and PCI-X for the Ethernet and SATA Ports.

This has 2 500GB maxtors, 2 250GB segates, 1 1TB Seagate for parity.

This ranged from 29,000KB/s to 45,000KB/s.

How many drives total?  I have 14 (including parity).  That might be part of the difference.

 

I've gotten speeds in the upper 50s when I've run tests with just a few drives.

 

Your idea of staggering the disk assignments is an interesting one.  May have to try an experiment with that.  (I think I'll add your post to the Best of the Forums, tweaks section.  Maybe people setting up their arrays would try it out and see if it makes a big difference).

 

My goal was really to free up some bandwidth so I can add 2-3 more disks to the PCI controller before parity speeds slow to over 8 hours.  (I want to try to keep them running in an overnight cycle.)

 

I've been thinking of creating a RAID-0 pair from 2 500G drives to use as parity.  That would actually free up one more slot, and would likely be a good thing for performance.

Do you still have a PCIe X1 slot open.

I'm assuming so because you are using the MB's JMICRON controller along with the PATA.

 

So you could add another two SATA drives with a PCIe card.

 

Another choice for RAID0 is an external box using the SIL Steelvine processor.

Although I'm not sure it would buy you as much as staggering the drives may.

 

Also, if you do go with Hardware RAID0 keep in mind the drives may not spin down.

In this case it may pay to do a SAFE33 or SAFE50 arrangement utilizing part for the cache (or os applications) and part for the parity.

 

Staggering the P-ATA drives may buy you a bit.

With PATA, you cannot access another drive on the same cable without the first one completing.

So if you have a read on one drive, the CPU must wait for that read to complete before issuing another. Same goes with writes.

Granted with a parity check/build all drives are read in succession, but I'm sure there would be some bus overhead in there somewhere.

 

I think the Promise TX4 controllers have a small FIFO and do some offloading of the CPU which is why they get good performance.

The P5B-VM DO does not have an x1 slot, just an x4 and an x16.  The x16 is open at this time.

 

One of my IDE (P-ATA)  drives is in the array (300G) and the other is my cache disk (also 300G).  It does not impact performance in parity rebuild.

 

The fact that the RAID 0 pair won't spin down is a bummer.  That may make me decide not to do that.  I guess the only way to know for sure, though, is to try it.  It would take some major reorging to get to that, though.  Likely something I consider when I need that last unRAID disk slot.  The other concern is would the RAID 0 pair be at least as big as a normal 1T drive.  That would be a problem if it wasn't big enough.

One of my IDE (P-ATA)  drives is in the array (300G) and the other is my cache disk (also 300G).  It does not impact performance in parity rebuild.

Absolutely correct there. I missed that.

 

As far as RAID0 Spindown, this would be possible if Tom were to implement it in the kernel.

I just have not seen it happen with hardware raid controllers (Although it "may" be possible).

I know with the SIL steelvine processor it did NOT spin down.

 

This is one of the reasons I'm a proponent of SAFE50/33 environment.

If you are going to have drives spinning. For example a RAID1 Cache, You might as well build an environment that encompasses a RAID1 cache and RAID0 Parity scheme.

In addition setting up an environment where you can install third party software.

 

In this case you have the best of all.

A Sanctioned place for software

A protected cache

A high speed consolidated parity drive.

 

If this were done in software raid with fancy partitioning, then spin down of these drives will be possible as long as they are not being accessed very frequently.

If they are being accessed frequently, well then you have the cache and/or parity drive readily available already.

 

If I were to implement the cache feature (something I do not do today) I would certainly do it with a SAFE50 environment because in respect, you would still have a drive for parity and a drive for cache.