Some RAID Benches (5, 6, 50, and 60): Areca 1680, VRaptors, 256 bit AES, etc.

[stevecs]

We would expect that RAID-0 (4 drive) should handle the same number of write operations as raid-10 (8 drive) but both RAID-10 (4 drive) and raid-0 (4 drive) should exhibit close to the same number of read operations (not exact as it depends on where you fall in relation to your stripe size) but it would be interesting to see both a 8 & 4 way raid-10 compared against a 4-way raid-0.

[Speederlander]

First RAID 10 results are now posted.

[Speederlander]

We would expect that RAID-0 (4 drive) should handle the same number of write operations as raid-10 (8 drive) but both RAID-10 (4 drive) and raid-0 (4 drive) should exhibit close to the same number of read operations (not exact as it depends on where you fall in relation to your stripe size) but it would be interesting to see both a 8 & 4 way raid-10 compared against a 4-way raid-0.

Well, I'm seeing an 8-drive RAID 10 lag behind 8-drive RAID 0 in reads. I'll try to do some variations on drive sizes with a 4 drive RAID 10 and a 4 drive RAID 0 once all the RAID 10 stuff is finished. I do plan on doing some stripe variation on the 10 and 60, with 128, 64 and 32 all run. One of those could even things out.

I will have some questions as to how the striping functions with a RAID 50/60 later I think.

[stevecs]

And I can expect that for general requests. Basically it should come down to the distribution of the requested blocks on the subsystem. If you're requesting blocks that fall on the 'same disk' for example in a raid-0 you should see 2x that for a raid-1 (10) as you have two copies. However if you are NOT doing that (ie, block request does not hit the same spindles) then you will see more from a raid-0. I don't use iometer so I don't know how you would show such a scenario.

And if you have time you may want to show the write/read differences between say a raid 5/6 of 4 drives and a raid-50/60 of 8 drives. The writes should increase by 2 (assuming perfectly balanced/random workload). reads should decrease (as you have less data drives, more parity drives) especially with such small arrays (4/8 drives)

[[XC] riptide]

My eyes! Need-graphs-WTF-BBQ!

Great stuff... you might run a few graphs at the end.

[Speederlander]

My eyes! Need-graphs-WTF-BBQ!

Great stuff... you might run a few graphs at the end.

Had big performance issues actually with this firmware. Just updated to 1.46 beta firm and performance is greatly altered (improved a lot in some cases, not so good for large queue depth situations). Unfortunately most of these numbers are out the door.

Once I figure out my path forward I'll probably be creating a new thread.

[stevecs]

What issues were you running into with the firmware? (also was it really the firmware or the transport or what?)

[Speederlander]

What issues were you running into with the firmware? (also was it really the firmware or the transport or what?)

Every sequential number I got, no matter what the benchmark, including iometer, seemed too low for an array of 8 velociraptors. I was also seeing a lot of settling; big variations in bench results from one run to the next, always moving to worse performance, sometimes going down 20% or more between run 1 and run 5 or 6. I was assuming it was just a function of SATA not playing so well on an Areca 1680 SAS controller. I bought the 1680 for RAID 6 performance anyway so I mostly didn't care. But it was still bugging me so I started looking a little closer. I found the 1.46 firmware beta (firm and boot only) and took a chance. I'm seeing up to 20% or better improvement in low queue depth sequential reads and writes, minor improvement in low queue depth random reads and writes, and an equivalent fall off (going from minor to pretty bad) in high queue depth operations. No more result fall-off now either. They are very stable.